This document defines mandatory security practices for all agents, developers, and automated systems working on this repository.

Security is not optional. Any code that violates these rules must be rejected.

This standard is aligned with:

• OWASP Top 10 (industry baseline) (OWASP Foundation)
• Microsoft ASP.NET Core security guidance (Microsoft Learn)

1. Never trust input

   • All input is untrusted
   • Validate server-side only
   • Reject or sanitise everything (OWASP Foundation)

2. No secrets in code

   • No API keys, passwords, connection strings in:

     • source code
     • config files
     • logs

   • Use secure secret stores (Azure Key Vault)

3. Authentication must be standard

   • No custom auth

   • Use:

     • OpenID Connect
     • OAuth2
     • Azure AD / Entra ID

4. All traffic must be encrypted

   • HTTPS only
   • Enforce HSTS
   • No insecure protocols (Escape)

5. Principle of least privilege

   • Every user, service, and API gets minimal access
   • Enforce authorisation on every request (Hicron Software)

• Use ASP.NET Core Identity or external providers

• Enforce:

  • MFA for privileged users
  • Strong password policies

• Always use:

  • [Authorize] attributes
  • Claims-based or role-based access

❌ Do NOT:

• Build custom login systems
• Store passwords in plain text

• Validate:

  • DTOs using DataAnnotations or FluentValidation

• Use:

  • Whitelisting over blacklisting

• Encode output:

  • Razor auto-encoding is mandatory

Protect against:

• XSS
• Injection attacks
• Logic abuse (C# Corner)

• Encrypt sensitive data:

  • At rest (AES-256 or platform equivalent)
  • In transit (TLS 1.2+)

• Use:

  • ASP.NET Core Data Protection APIs

• Never log:

  • PII
  • credentials
  • tokens

• Always use:

  • Entity Framework or parameterised queries

• Never:

  • concatenate SQL strings

Example (safe):

var user = db.Users.FirstOrDefault(u => u.Id == id);

• Require authentication for all endpoints by default

• Explicitly allow anonymous only where justified

• Implement:

  • Rate limiting
  • API keys or tokens
  • Request size limits

• Validate:

  • JSON payloads
  • headers
  • query parameters

• Cookies must be:

  • Secure
  • HttpOnly
  • SameSite=Strict

• Do NOT:

  • store tokens in localStorage (for browser apps)
  • expose session IDs

All responses must include:

• Content-Security-Policy
• X-Content-Type-Options
• X-Frame-Options
• Strict-Transport-Security

(Security headers reduce browser-based attacks) (OWASP Foundation)

• Scan dependencies continuously

• Block builds if:

  • known vulnerabilities exist

• Tools:

  • Snyk / Dependabot / OSS Index

• Log:

  • authentication failures
  • access violations
  • suspicious activity

• Never log:

  • secrets
  • tokens
  • full request bodies

• Ensure logs are:

  • tamper-resistant
  • centrally stored

• Enforce:

  • environment separation (dev/test/prod)

• Disable:

  • debug mode in production

• Restrict:

  • IP access where possible

• Use:

  • Managed identities instead of credentials

Do NOT use:

• BinaryFormatter
• .NET Remoting
• DCOM
• Partial trust code (Microsoft Learn)

All new features must:

• Identify:

  • attack surface
  • data flows

• Consider:

  • OWASP Top 10 risks

• Document:

  • mitigation strategies

Every PR must pass:

• Static analysis (SonarQube or equivalent)
• Dependency vulnerability scan
• Secret scan

❌ Auto-reject if:

• Critical vulnerabilities detected
• Secrets exposed

Minimum:

• Authentication tests
• Authorisation tests
• Input validation tests

Recommended:

• Automated security scans
• Pen testing for major releases

• “We’ll fix security later” → you won’t
• Custom auth → always broken
• Logging everything → data breach waiting to happen
• Over-permissive APIs → easiest exploit path

• Secure by default
• Deny by default
• Explicitly allow only what is required

If there is uncertainty:

Fail closed, not open

If you want, I can tighten this further into:

• CI/CD YAML enforcement
• Azure-native version (Key Vault, Managed Identity, App Gateway WAF)
• Sonar ruleset + policy as code

That’s where this really becomes enforceable rather than just documentation.