Security Hardening 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.