What I Do to Make a .NET Application Safer

Application security is not only about adding authentication. It also involves protecting the code, infrastructure, data, dependencies, and development process.

Use version control properly

Git helps track changes, review code, and recover from mistakes.

However, sensitive files should never be committed. I use .gitignore to exclude local configuration, secrets, and generated files.

appsettings.Development.json
.env
*.user

Repositories should also use pull requests and code reviews before important changes are merged.

Never hardcode secrets

Passwords, connection strings, API keys, and JWT signing keys should not be stored directly in the source code.

var connectionString =
    builder.Configuration.GetConnectionString("DefaultConnection");

During development, I use .NET User Secrets. In Azure, secrets can be stored in Azure Key Vault or provided through secure environment configuration.

Protect API endpoints

Endpoints should be protected using authentication and authorization.

[Authorize]
[HttpGet("profile")]
public IActionResult GetProfile()
{
    return Ok();
}

For restricted operations, I use roles or authorization policies:

[Authorize(Roles = "Admin")]

Public endpoints should be intentional. Sensitive operations should never depend only on the frontend hiding a button.

Configure JWT carefully

JWT can be used to authenticate requests, but tokens must be validated correctly.

The API should validate the issuer, the audience, the signature, and the expiration time.

Tokens should have a reasonable lifetime, and signing keys must be protected. JWT payloads are encoded, not encrypted, so passwords or sensitive information should never be placed inside them.

Follow RBAC and least privilege

AZ-900 introduced me to Azure Role-Based Access Control. RBAC defines who can access a resource and what actions they can perform.

The same principle applies inside an application. Users, services, and database accounts should receive only the permissions they need. An application database account should not automatically have administrator access to the entire database server.

Use HTTPS

HTTPS protects communication between clients and the API.

app.UseHttpsRedirection();

Production applications should use valid TLS certificates and avoid exposing sensitive endpoints through unencrypted HTTP.

Monitor the application

Logs help identify errors, suspicious activity, and performance problems. Tools like Grafana can display dashboards using metrics collected from the application and infrastructure.

Useful signals include failed login attempts, high error rates, unusual request volume, slow endpoints, and CPU or memory usage. Logs should never contain passwords, access tokens, or complete sensitive data.

Use trusted and updated dependencies

Every dependency adds code that I didn't write but that my application still depends on. Before installing a package, I check whether it's actively maintained, whether it comes from a trusted source, whether it has known vulnerabilities, and whether the application really needs it.

Packages should be updated carefully, tested, and reviewed rather than installed automatically without understanding their impact.

Review LLM-generated code

LLMs can help generate code, configuration, and infrastructure files, but their output should never be accepted blindly. I always review every command before running it, every package being installed, authentication and authorization changes, database migrations, secrets and configuration, Docker and deployment files, and any code that deletes or modifies data.

The developer remains responsible for the final code.

Final checklist

Use version control and code reviews.
Never hardcode secrets.
Protect sensitive endpoints.
Validate JWT tokens correctly.
Apply RBAC and least privilege.
Use HTTPS.
Monitor logs and metrics.
Use trusted dependencies.
Review all LLM-generated code.

Security is not a feature added at the end. It should be part of every stage of development.