Security Compliance

Security & Compliance Standards

This skill defines mandatory security and compliance patterns. Violations of these patterns are blocking issues in code review.

Auth0 Integration

Backend (ASP.NET Core)

builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(options =>
    {
        options.Authority = $"https://{config["Auth0:Domain"]}/";
        options.Audience = config["Auth0:Audience"];
        options.MapInboundClaims = false;  // CRITICAL: preserves "sub", "email" claim names
        options.NameClaimType = "sub";
    });

CRITICAL: MapInboundClaims = false prevents ASP.NET from remapping JWT claims to XML namespace URIs. Without this, User.FindFirst("sub") returns null.

Claims Extraction

private string CurrentUserId => User.FindFirst("sub")?.Value
    ?? throw new UnauthorizedAccessException("No sub claim");
private string? UserEmail => User.FindFirst("email")?.Value;

Frontend (Auth0 React SDK)

// Token accessor for API client
const { getAccessTokenSilently } = useAuth0()
setTokenAccessor(() => getAccessTokenSilently())

• Tokens stored in memory only — NEVER localStorage or sessionStorage
• Use Auth0's built-in refresh token rotation
• AuthGate component handles login redirect + user provisioning

Token Best Practices

• Access tokens: Short-lived (5-15 min), stored in memory
• Refresh tokens: HttpOnly cookie or Auth0 SDK rotation
• ID tokens: Never sent to APIs — use access tokens
• For BFF pattern: Backend holds tokens, frontend uses session cookies

OWASP Top 10 Mitigations

1. Injection (SQL, NoSQL, Command)

• Use parameterized queries (EF Core does this by default)
• Never concatenate user input into SQL: $"SELECT * FROM users WHERE id = '{id}'" is FORBIDDEN
• Dapper: Always use @param parameters, never string interpolation

2. Broken Authentication

• Auth0 handles password hashing, MFA, brute-force protection
• Implement account lockout for custom auth flows
• Never log tokens or passwords

3. Sensitive Data Exposure

• TLS everywhere (enforced at infrastructure level)
• Encrypt PII at rest (see PII section below)
• Never return sensitive fields in API responses (passwords, tokens, full ID numbers)

4. XXE (XML External Entities)

• Don't parse XML from user input; use JSON exclusively

5. Broken Access Control

• [Authorize] at controller level, [AllowAnonymous] per-method only when justified
• Always filter by CurrentUserId or TenantId in queries — never trust client-provided IDs
• Check ownership: if (goal.UserId != CurrentUserId) return Forbid();

6. Security Misconfiguration

• Remove Swagger in production: if (app.Environment.IsDevelopment()) app.UseSwagger();
• Set security headers (CSP, X-Frame-Options, HSTS)
• Never expose stack traces in production error responses

7. XSS (Cross-Site Scripting)

• React auto-escapes JSX by default — never use dangerouslySetInnerHTML
• Sanitize markdown rendering if accepting user-generated content
• CSP headers: Content-Security-Policy: default-src 'self'

8. Insecure Deserialization

• Use System.Text.Json with strict type handling
• Never deserialize untrusted data into arbitrary types

9. Insufficient Logging

• Log authentication events (login, logout, failed attempts)
• Log authorization failures
• Log data access patterns for sensitive resources
• NEVER log tokens, passwords, or PII

10. SSRF (Server-Side Request Forgery)

• Validate and allowlist URLs before making backend HTTP calls
• Never let user input control entire URLs for backend fetches

PII / Data Protection Compliance

What is PII in Our Systems

Data Protection Requirements

1. Explicit consent: Collect only with clear, specific consent
2. Purpose limitation: Use PII only for the stated purpose
3. Data minimization: Collect only what's needed
4. Breach notification: Report compromises to the relevant authority promptly
5. Right to erasure: Users can request complete deletion of their PII
6. Accountability: Organization must have a designated data protection officer/role

Implementation Patterns

Encryption at Rest

// Use ASP.NET Core Data Protection for column-level encryption
public class EncryptedStringConverter : ValueConverter<string, string>
{
    public EncryptedStringConverter(IDataProtector protector)
        : base(v => protector.Protect(v), v => protector.Unprotect(v)) { }
}

Masking in Logs

// NEVER log PII directly
_logger.LogInformation("User {UserId} updated profile", userId);  // OK
_logger.LogInformation("User {Email} logged in", email);  // FORBIDDEN

Masking in UI

// Show only last 4 digits of ID numbers
function maskId(id: string): string {
  return '\u2022'.repeat(id.length - 4) + id.slice(-4)
}

Right to Erasure

public async Task EraseUserDataAsync(Guid userId, CancellationToken ct)
{
    // Cascade delete all PII — keep only anonymized transaction records
    var user = await _db.Users.Include(u => u.Profile).FirstAsync(u => u.Id == userId, ct);
    user.Email = $"deleted_{userId}@erased.local";
    user.Profile.FirstName = "Deleted";
    user.Profile.LastName = "User";
    user.Profile.Phone = null;
    // ... scrub all PII fields
    await _db.SaveChangesAsync(ct);
}

PCI DSS 4.0 (Payment Card Data)

Scope Reduction

• NEVER store card numbers (PAN) — use payment processor tokenization (e.g., Stripe)
• Use hosted payment forms (Stripe Elements, processor ACH forms) to keep card data off our servers
• If PAN must transit our backend: encrypt immediately, log only last 4 digits

Requirements

• TLS 1.2+ for all cardholder data in transit
• Strong cryptography for stored cardholder data (AES-256)
• Unique user IDs for system access
• Restrict access to cardholder data on a need-to-know basis
• Log and monitor all access to cardholder data
• Regular vulnerability scans

Our Approach

Use third-party payment processors (e.g., Stripe) that handle PCI compliance. Our responsibility is:

1. Never store raw card data
2. Use tokenized references only
3. Secure API keys for payment services
4. Log payment events (amounts, status) without card details

Secrets Management

Rules

• Environment variables for all secrets — never in code or config files
• .env files: NEVER committed, listed in .gitignore
• API keys: Backend only — NEVER in frontend code
• Auth0 client secrets: Backend only
• Database passwords: Environment variables
• Third-party API keys: Backend only, use appropriate auth scheme (e.g., HTTP Basic, Bearer)

Configuration Pattern

// appsettings.json — structure only, no values
"ExternalService": {
  "ApiKey": "",    // Set via EXTERNALSERVICE__APIKEY env var
  "ApiSecret": ""  // Set via EXTERNALSERVICE__APISECRET env var
}

Deployment

• Secrets set as platform-specific service variables (e.g., Railway, Azure, AWS)
• Never in Dockerfiles or docker-compose.yml production configs
• Use platform-native reference variables for cross-service secrets

Audit Trail

For sensitive operations, log:

public record AuditEntry(
    string Action,      // "user.profile.updated", "goal.created", "deposit.initiated"
    string UserId,
    string ResourceType,
    string ResourceId,
    DateTimeOffset Timestamp,
    Dictionary<string, object?> Metadata  // Changed fields, but NO PII values
);

• Log WHO did WHAT to WHICH resource, WHEN
• Never log the actual PII values in audit entries
• Retain audit logs per regulatory requirements