csharp-database-secure-no-railguard-available

R: Risk First

The goal of this rule is to ensure safe, auditable, and robust database access in C# applications.

Key risks mitigated:

• SQL injection via unsafe query strings
• Hardcoded or leaked credentials
• Misconfigured or unsafe ORM operations
• Lack of input validation in query construction
• Logging of sensitive database values

This rule prepares the model to reason securely about database operations, regardless of whether the user explicitly mentions injection, credentials, or ORM.

A: Attached Constraints

• Never use string concatenation to build SQL queries.
• Never log raw SQL statements containing user-provided data.
• Never hardcode sensitive values (for example, DB credentials) in source code.
• Use SqlCommand with Parameters.Add() or LINQ-to-Entities.
• ORM operations must use proper configuration and input protection.
• Always wrap raw ADO.NET operations in a try/catch block and check exceptions.

I: Interpretative Framing

• If the prompt involves DB access, assume secure credential loading and parameter binding are required.
• If EF Core is mentioned or used, enforce use of LINQ and strongly typed models.
• If manual SQL is required, enforce use of SqlCommand.Parameters.Add() and no dynamic string interpolation.
• If secrets are referenced, redirect to using .NET Secret Manager, Azure Vault, or environment-based config.

// Examples:

• If the user says “select user by name,” the model must return code that uses a parameterized query.
• If SqlConnection is used, assume a config-based ConnectionString source.

L: Local Defaults

• ORM: Entity Framework Core with DbContext, DbSet<T>
• Credential source: appsettings.json or environment variables
• Default DB logging behavior should avoid showing queries with raw input

// appsettings.json
"ConnectionStrings": {
  "DefaultConnection": "Server=...;Database=...;User Id=...;Password=...;"
}

G: Generative Path Checks

1. Determine if ORM is present (EF Core)
2. If not, enforce parameterized query via SqlCommand
3. Sanitize all input values before adding them as parameters
4. Never build SQL using string interpolation ($"...") or +
5. Ensure try-catch-finally or using-disposal pattern is applied
6. Check logging or error messages for any exposed sensitive data