Secure Coding Standards

Rust FHE / PQ Cryptographic Engine

Memory Safety

• No unsafe blocks without documented justification, security review, and approval by the Security Officer
• All approved unsafe blocks must be annotated with // SAFETY: comments explaining the invariants that make the code safe
• Key material must be zeroed on drop using the zeroize crate (implement Zeroize and ZeroizeOnDrop traits)
• No use of std::mem::transmute for type conversions in cryptographic code; use safe alternatives

Constant-Time Operations

• All cryptographic operations must be constant-time: no data-dependent branches, no data-dependent memory access patterns, no data-dependent loop counts
• Use constant-time comparison functions for secret data (e.g., subtle::ConstantTimeEq)
• Avoid early returns in functions processing secret data
• NTT butterfly operations must use arithmetic (not conditional) reduction

FHE Parameter Validation

• Reject parameter downgrade attacks: minimum polynomial degree N=4096, minimum ciphertext modulus Q of 56 bits
• Validate plaintext modulus t satisfies CRT condition: t must be congruent to 1 (mod 2N)
• Enforce domain conventions: secret keys in NTT form, ciphertexts in coefficient form (except multiply_plain_ntt() output which is NTT form)
• Montgomery form arithmetic required for all hot-path NTT operations

Logging and Error Handling

• No plaintext PHI, biometric templates, cryptographic key material, or secret parameters in logs, error messages, or debug output
• Use structured error types; avoid .unwrap() in production code paths (use ? operator or explicit error handling)
• Panic handlers must not leak sensitive state

Dependencies

• Dependencies audited weekly via cargo audit
• No new cryptographic dependencies without Security Officer review (H33 uses proprietary implementations)
• All dependencies pinned to exact versions in Cargo.lock

Node.js Auth1 Microservice

Input Validation

• All API endpoints must validate input using express-validator or equivalent middleware
• Reject unexpected fields (allowlist approach, not denylist)
• Validate and sanitize email addresses, phone numbers, and all user-provided strings
• Enforce maximum request body sizes

Database Security

• Parameterized SQL queries only — no string concatenation or template literals for query construction
• Use query builder or ORM with parameterized queries
• Database connection strings stored in environment variables, never in source code
• Connection pooling with defined limits to prevent resource exhaustion

Authentication and Sessions

• Rate limiting on all public endpoints (especially /api/auth/request, /api/auth/verify)
• Auth cookies must use httpOnly, Secure, and SameSite=Strict flags
• Session tokens must be cryptographically random (minimum 128 bits of entropy)
• No sensitive data in localStorage — use httpOnly cookies exclusively for authentication state

Secret Management

• No secrets (API keys, tokens, passwords, connection strings) committed to source code or logged
• Environment variables for runtime configuration; AWS Secrets Manager for production credentials
• Dependencies audited via npm audit before each release

JavaScript Frontend

XSS Prevention

• Use textContent for DOM manipulation with user data — never innerHTML with untrusted content
• No eval(), Function() constructors, or setTimeout/setInterval with string arguments
• Content Security Policy (CSP) headers enforced: script-src restricted to same-origin and trusted CDNs

Data Handling

• No sensitive data in localStorage or sessionStorage — authentication tokens stored in httpOnly cookies only
• No PII or PHI cached on the client side beyond the current session
• Form data cleared from memory after submission

Third-Party Scripts

• Third-party scripts loaded with integrity attributes (Subresource Integrity / SRI) where available
• Third-party scripts reviewed for security before inclusion
• No inline scripts in HTML; all JavaScript in external files