Security Hardening code review rules

Check if user inputs are sanitized before being used in rendering or database queries. Unsanitized inputs can lead to injection vulnerabilities like XSS or SQL injection.

Ensure that SSL/TLS certificate validation is always enabled to prevent Man-in-the-Middle (MitM) attacks.

Detect modifications to built-in prototypes. Modifying built-in objects can lead to compatibility issues and unexpected behavior. Recommend creating helper functions instead.

Check if HTTP request redirections are unvalidated. Allowing arbitrary redirections can expose users to phishing attacks. Recommend validating and restricting URLs.

Detect the use of eval(). Eval allows execution of arbitrary code, leading to security vulnerabilities such as code injection. Recommend safer alternatives like function execution.

Handlers must verify the requester’s role and a valid consent/relationship (e.g., care team assignment) before disclosing ePHI; include Purpose-Of-Use in the decision and audit the outcome.

If data subject is a child/adolescent, require age verification and parental/legal guardian consent prior to processing; deny processing otherwise and do not store the payload.

Ensure that a new session is always created upon user authentication to prevent session fixation attacks.

Disabling CSRF protection allows attackers to trick users into performing unintended actions, such as modifying account details or making unauthorized transactions.

Never store CVV/CVC or other SAD after authorization in databases, caches, files, or telemetry. Schema/models must not define fields for CVV/CVC; reject writes containing cvv/cvc keys. (PCI DSS 4.0 Req. 3.2.1)

For Ingress/Service of type LoadBalancer, require host/path allowlist and TLS; forbid 0.0.0.0/0 exposure without WAF or Auth.

Ensure that external user input is properly sanitized before being used to define environment variables.

Before persisting ePHI, encrypt using a data key protected by a Key Management Service (KMS). Use authenticated encryption (AES-256-GCM or equivalent), rotate keys, and store the key id and algorithm with the record.

For fields like CPF, birth_date, and address, use AES-256-GCM with envelope encryption. Keys must come from a managed KMS; rotate data keys at least annually and store key IDs with the ciphertext.

Use envelope encryption (AES-256-GCM) with cloud KMS-managed CMKs for databases, object storage, and backups. Rotate CMKs at least annually and rotate DEKs per object/file.

Public services must require TLSv1.2 or higher and set HSTS (max-age ≥ 15552000, includeSubDomains). Reject plaintext HTTP and weak ciphers; cookies must be Secure and HttpOnly with SameSite set.

Ensure that deserialization processes validate untrusted data before processing to prevent code execution vulnerabilities.

Unit tests must stub or fake external HTTP/DB calls; allow real I/O only in integration/e2e tests tagged accordingly.

Set securityContext.runAsNonRoot=true, runAsUser!=0, and readOnlyRootFilesystem=true on pods/containers.

Allowing untrusted data to be executed dynamically can lead to arbitrary code execution and security vulnerabilities. Always validate input before execution.

Deserializing untrusted data can allow attackers to execute arbitrary code. Always validate and sanitize serialized inputs before processing.

Ensure that the application does not disclose file existence based on user input to prevent filesystem oracle attacks.

Ensure that applications do not expose intent-processing components that can be manipulated by other applications.

Unsanitized user input in NoSQL queries can allow attackers to manipulate database queries, leading to data leaks or unauthorized modifications.

Ensure that user-controlled HTTP redirections are validated to prevent phishing attacks.

Ensure that URLs used in redirection are properly validated and restricted to trusted domains. Open redirects can be exploited to redirect users to malicious sites.

Ensure that all user inputs related to file paths are validated and sanitized to prevent path traversal attacks.

Ensure that all user inputs in templates are properly validated and sanitized to prevent SSTI attacks.

Using unsanitized user input in SQL queries can lead to SQL injection attacks. Use parameterized queries to protect against malicious inputs.

Ensure that user-controlled data is not used to suspend threads, as it can lead to Denial of Service (DoS) attacks.

In Pulumi TypeScript programs, load sensitive values with new Config().requireSecret and pass as Secret<T>, never plain strings.

Before handling sensitive personal data (e.g., health, biometric), verify a valid consent record and attach its ID to the processing context. Provide a path to revoke consent and stop further processing.

Allowing user input in connection strings can lead to injection attacks. Always validate and sanitize inputs before constructing connection strings.

Identify server-side requests that do not validate input sources. SSRF vulnerabilities allow attackers to make unauthorized requests on behalf of the server. Restrict and validate request sources.

Disabling SSL/TLS certificate validation exposes applications to Man-in-the-Middle (MitM) attacks, compromising security.

Skipping certificate validation enables attackers to impersonate trusted entities and intercept secure communications.

Validate required parameters at boundaries using require/requireNotNull or explicit validators; fail fast with actionable messages.

Validate method inputs up front with null checks or use Objects.requireNonNull and meaningful messages.

Validate presence, format, and ranges for incoming parameters before processing.

Validate presence, type, and range of critical inputs at boundaries (API, CLI, jobs) and fail fast with clear messages.

Serve via rustls with TLS1.2+ and add middleware to log JSON audit events with user_id and request_id; never log raw tokens.

Enforce uniqueness at the database level (unique indexes/constraints) for identifiers and natural keys.

Failing to check `ModelState.IsValid` before processing user input can result in invalid or unverified data being accepted.

Protect /exports/ with role checks, fresh MFA, and rate limits; add requester and approved_by to the audit event.

Whenever PII is read, emit an audit event capturing actor, purpose, fields touched, and legal basis; never include raw PII in the audit payload—store hashes/tokens only.

Check for occurrences where user input is directly used to construct system commands. This introduces a risk of command injection. Suggest using parameterized queries or safe wrappers instead.

Passing user input directly into system commands can lead to command injection vulnerabilities. Always sanitize inputs before execution.

Do not use the eval() function to run dynamically generated PHP code, especially if it can include user input. Look for safe alternatives like controlled function calls or explicit decision structures.

Add a 'Security & Privacy' section in ADRs addressing threat model impacts, secrets handling, data retention, and PII processing; link to relevant runbooks and DPA if applicable.

Provide a single permission check API (e.g., can(user, action, resource)) and reuse it across layers.

When accepting a slice or map from external snippet or returning one, consider copying it. This prevents unintentional modifications to the original data. For example, don't store a slice argument directly if the caller might modify it later; instead, make a copy for internal use.

If a PR introduces workloads in a namespace that lacks a default-deny NetworkPolicy, add one plus explicit allow rules.

All bulk exports of PII require approval, step-up MFA, rate limits, and watermarking of files with requestor and timestamp; record export_id in the audit log.

Require TOTP or WebAuthn MFA for admin areas; verify mfa_verified_at timestamp before sensitive routes.

Avoid using directives or features that bypass Vue's built-in HTML escaping mechanisms, such as the `v-html` directive, unless the content is known to be safe or has been properly sanitized.

Registry configuration (e.g., .npmrc, .yarnrc.yml) must live at the monorepo root. Forbid .npmrc files inside workspace packages overriding registry auth or URL.

Configure your application not to display detailed error messages (stack traces, PHP warnings) to end users in production. Instead, log errors for developers and show a generic message to users.

Avoid passing untrusted values to include/require statements. If you need to include files based on external input, strictly validate that input (for example, using a whitelist of valid filenames).

Never write Protected Health Information (PHI/ePHI) to logs. Redact fields like name, SSN, MRN, DOB, address, diagnoses, and lab results; store only non-identifying metadata and a stable request trace id. If logging is required for troubleshooting, replace values with consistent tokens and record access separately in the audit log.

Ensure that CSRF protection is enforced. Disabling CSRF protection allows malicious sites to execute unauthorized actions on behalf of authenticated users.

When sending session or other sensitive cookies, always enable the HttpOnly and Secure flags (and consider SameSite). HttpOnly prevents JavaScript access, and Secure ensures the cookie is only sent over HTTPS.

Use AES-GCM with keys from KMS to encrypt sensitive columns (e.g., SSN) before saving; store nonce and auth tag; never rely solely on disk encryption.

Encrypt sensitive columns (e.g., email, phone) with managed keys; ensure DB connection enforces TLS. Store only ciphertext; compare via deterministic token/hashes when needed. (GDPR Art. 32)

If PAN must be handled transiently, encrypt in memory with AES-256-GCM using a KMS/HSM-provided key, store only ciphertext or tokens, and zeroize plaintext buffers immediately. Rotate keys per policy. (PCI DSS 4.0 Req. 3)

Allowing anonymous LDAP connections exposes directory data to unauthorized users. Always require authentication.

Use helmet to set HSTS and configure cookies with Secure, HttpOnly, and SameSite. Reject HTTP by redirecting to HTTPS.

Install HSTS in Ktor, require HTTPS redirects, and emit structured audit events for role changes with callId/traceId.

Force HTTPS via middleware, set HSTS, and configure session cookies with secure=true, http_only=true, same_site=lax or strict in config/session.php.

Use Spring Security to require HTTPS, enable HSTS, set session fixation protection, and configure SameSite, Secure, HttpOnly cookies.

Grant production access just-in-time via approved requests with scoped durations; break-glass access must trigger alerts and expanded audit logging.

Applications serving ePHI must require HTTPS, disable insecure ciphers, and enable HSTS with preload and includeSubDomains. Reject cleartext HTTP requests.

All outbound connections that may carry CHD/PAN tokens must enforce TLS >= 1.2, validate hostname/chain, and optionally pin gateway SPKI. Disable insecure ciphers/versions. (PCI DSS 4.0 Req. 4)

Always escape or sanitize user‐provided content before displaying it in HTML. Use functions like htmlspecialchars() to convert special characters into HTML entities.

Enable config.force_ssl = true; add filter_parameters to redact PII and secrets; use secure_same_site for cookies.

Any code path that reads, decrypts, or exchanges PAN tokens must require an explicit authorization policy (e.g., role "pci:read_token") and log access without PAN. Deny by default. (PCI DSS 4.0 Req. 7 & 10)

Set session idle timeout ≤ 15 minutes and absolute timeout ≤ 12 hours; cookies must be Secure, HttpOnly, and SameSite=Lax or Strict; revoke sessions on password change.

Use a builder stage for toolchains/dev deps and a minimal runtime stage that contains only runtime artifacts.

Authorize every request by role and resource scope. Policies must default-deny and require explicit allow; privileged roles (admin, auditor) must be rare and reviewed quarterly.

Before sending PII to processors, verify the destination region is approved (e.g., BR/EEA with SCC/DPA). Block requests that include personal data and target non-approved regions.

Access tokens, HMAC salts, and KMS keys for PHI flows must come from a secret manager or encrypted credentials store; forbid committing secrets or .env files to the repo.

Keep middleware fast and side-effect free (no DB writes). Narrow the matcher and skip static assets. Use Route Handlers for heavy logic.

Configure Spring Boot to require client certificates for internal APIs (clientAuth=REQUIRE) and restrict CAs; log peer certificate subject in audit events.

Read secrets (process.env.*) only in Server Components, Route Handlers, or server actions. Client Components must use ONLY NEXT_PUBLIC_* variables.

Use immutable image digests (repo@sha256:...) instead of mutable tags for production workloads.

Provide an authenticated endpoint that assembles a user's data into a structured JSON export and returns a short-lived signed URL (≤24h). Include integration tests in the PR. (GDPR Art. 20)

Check if memory allocation sizes are derived from untrusted input. Attackers may exploit this to crash the program or consume excessive resources. Recommend validating and limiting allocation sizes.

Reflection methods that process untrusted input can be exploited for remote code execution. Always validate and sanitize external input before using reflection.

Ensure that server-side requests are properly validated to prevent SSRF attacks.

Write ePHI backups to storage with server-side encryption (SSE-KMS) and least-privilege access; disallow public ACLs and cross-account access without a BAA. Record the KMS key id in metadata.

Implement anti‐CSRF tokens in forms performing sensitive actions (like state changes or deletions). Generate a unique token per session or request and validate it on the server before processing the form action.

Use headers() and cookies() in Server Components, Route Handlers, or server actions; never in Client Components.

Logging/metrics must redact or hash personal data; attach lawful_basis and purpose to diagnostic context; forbid raw PII in logs. (GDPR Art. 5(1)(c) data minimization)

CI must run fmt/validate, produce and upload a plan artifact (e.g., terraform plan -out plan.bin), run policy-as-code (e.g., tfsec/checkov/conftest), and gate apply on manual approval for prod.

Use app.UseHsts(); app.UseHttpsRedirection(); store DataProtection keys in Azure Key Vault or KMS with rotation.

Endpoints under /admin or privileged routes that can view or export ePHI must enforce multi-factor authentication and recent re-auth (e.g., within 15 minutes).

Actions like role changes, key rotations, and exports of PII require MFA re-authentication within the last 5 minutes; record mfa_verified_at in the audit log.

Configure http.Server with tls.Config{MinVersion: tls.VersionTLS12} and set cookies with Secure, HttpOnly, SameSite.

Handlers must return non-2xx status codes for error outcomes and include a minimal error body that does not leak sensitive details.

Without a timeout, regex processing on untrusted input can be exploited for Denial-of-Service (DoS) attacks. Always define a timeout when using regex.

Never hardcode credentials (API keys, tokens, private keys) in source code, configs, or tests. If a string looks like a credential based on context (variable name, header usage, auth flows), treat it as a secret even if it is not high-entropy. Move it to env/secret manager, rotate the credential if it may have leaked, and remove it from git history if necessary.

For web/mobile payment forms, send PAN and CVV directly to the PCI-compliant gateway to obtain a single-use token; submit only the token to your backend. Validate that backend APIs reject requests containing PAN/SAD. (PCI DSS scoping & SAQ A)

For security tokens (session IDs, CSRF tokens, password‐reset links), use cryptographically secure random functions like random_bytes() or openssl_random_pseudo_bytes(), instead of predictable functions like rand() or mt_rand().

Do not build SQL queries by directly concatenating untrusted data. Instead, use prepared statements with parameters (for example, using PDO or MySQLi) to prevent SQL Injection.

Prefer app/api route handlers over legacy pages/api. Return NextResponse.json, validate input, and handle allowed HTTP methods explicitly.

Do not use weak or generic hash algorithms (like MD5 or SHA1) for storing passwords. Use built‐in functions like password_hash() (with BCRYPT or Argon2) and password_verify(), which handle salting and secure algorithms automatically.

Prefer TryParse-style APIs for user/IO input instead of Parse, and validate culture/format where applicable.

Never trust data received from users, forms or requests. Always validate the expected format (e.g., numbers, emails) and sanitize/remove unexpected characters or content using appropriate techniques (filter_var, filter_input, etc.).

After decoding, assert required keys and types before use; reject unexpected shapes.

If a PR changes redirect/header configuration (e.g., middleware redirects, CDN headers, security headers), validate it against the active edge rules to avoid conflicts. - If a Cloudflare MCP is available: fetch active rules and detect potential redirect loops, duplicate rules, or header conflicts. - Otherwise: require the author to link the relevant Cloudflare rules/screenshots in the PR description.

Validate and sanitize all request bodies and search params on the server using a schema (e.g., zod). Reject invalid payloads with proper status.

For any handler that reads or writes ePHI, write an append-only audit record with user id, patient id, action (READ_PHI/WRITE_PHI), purpose-of-use, timestamp, and request id. Prevent deletion or mutation of audit entries.

Ensure that JSON data is validated before parsing. Parsing untrusted JSON without validation can result in runtime errors or vulnerabilities.

Ensure that console statements are removed in production code. Console logs can expose sensitive data and impact performance.

Do not include internal identifiers (DB IDs, service IDs, tokens) in client-facing errors. Log them internally; return generic messages externally.

Identify `rescue Exception` statements and suggest replacing them with `rescue StandardError` to avoid catching critical system exceptions.

Ensure that CORS policies are properly defined. Weak or missing CORS policies may allow unauthorized domains to access your resources, leading to security vulnerabilities.

Configure CookiePolicyOptions to enforce SameSite=Lax or Strict, HttpOnly, and Secure for all auth cookies.

When configuring processors outside the EEA, annotate the config with transfer_mechanism (e.g., SCCs) and link to the signed SCC document; prevent enablement without this metadata. (GDPR Art. 46)

Set APP_DEBUG=false and hide stack traces; send errors to a centralized logger with trace_id instead.

Check for missing or incorrect autocomplete attributes. Proper use of autocomplete improves accessibility and usability, especially for screen readers.

Check for the use of eval() to handle asynchronous execution. Eval leads to security vulnerabilities. Recommend using Async/Await or Promises instead.

Validate CPF/CNPJ format and checksum server-side; reject storage of invalid identifiers and never auto-correct them. Store normalized (digits-only) representation.

Register a Monolog processor to mask emails/phones and attach pii_redacted:true; forbid direct logging of raw identifiers.

Expose constant dicts as read-only via MappingProxyType (or frozen dataclasses) to prevent runtime mutation.

Default to private visibility; expose the minimal surface and prefer val with private set when mutation is needed.

For simple form submissions from RSC, use server actions with schema validation and then revalidate paths/tags. Avoid client fetch for trivial mutations.

Pin cryptography libraries to vetted versions (e.g., BouncyCastle FIPS) and generate a CycloneDX SBOM as part of the build. Reject PRs introducing floating or insecure versions. (PCI DSS 4.0 Req. 6 & supply chain)

Ship only runtime artifacts (binaries, compiled assets, minimal configs). Exclude tests, sources, docs, and dev tooling.

Use safe casts (as?) with null checks or require statements instead of unchecked as.

Do not expose full, unminified source maps publicly in production. If source maps are required for error tracking, serve them behind authentication or IP allowlists and set "X-Robots-Tag: noindex".

Expose DTOs/ViewModels from API endpoints; avoid leaking persistence/domain entities directly.

If user input is used in OS command arguments, it can be manipulated to expand access or execute unintended commands. Ensure proper sanitization to prevent injection.

Add middleware to set HSTS, X-Content-Type-Options, and secure cookies; log JSON with actor and trace_id for auth and admin routes.

Serve assets with accurate Content-Type (e.g., text/css, application/javascript, image/avif, image/webp, font/woff2, image/svg+xml) and include charset for text types. Do not default to text/plain or application/octet-stream.

Check for the use of graphql-upload. This library enables file uploads using multipart requests, which can be exploited for CSRF attacks if not properly secured.

For third-party scripts, use <Script> with an appropriate strategy and onLoad callbacks. Avoid dangerouslySetInnerHTML for scripts.

Accept only short-lived tokens from the gateway (JWT/JWE or opaque) and validate signature/expiry; do not persist tokens beyond business need. Never attempt to reconstruct PAN from tokens. (PCI DSS data minimization)

Use instanceof/pattern matching and guard before casts; avoid ClassCastException.