Every Financial Data Encryption Audit check

Unencrypted financial data at rest — account numbers, SSNs, card tokens, transaction history — is a direct path from database breach to identity theft and fraud. CWE-311 (missing encryption) and CWE-326 (inadequate key length) are both in play when a project stores plaintext or uses AES-128: attackers who exfiltrate the database file get immediately usable cardholder data. NIST SP 800-111 and PCI-DSS 4.0 Req-3.5 require AES-256 or stronger because shorter keys are vulnerable to brute-force as compute costs fall. A single exposed plaintext column is enough to trigger breach notification obligations and PCI fines.

Why this severity: Critical because a single unencrypted sensitive column converts a database read vulnerability into direct cardholder data exposure with no further attacker effort required.

CWE-311 and CWE-312 describe the same failure at two layers: storing sensitive data without encryption (CWE-311) and storing passwords or credentials in a recoverable format (CWE-312). When neither TDE nor column-level encryption is present, every backup file, DB replica, and read replica contains plaintext cardholder data. PCI-DSS 4.0 Req-3.4 requires protection of stored cardholder data; NIST SC-28 requires protecting the confidentiality of data at rest. A breach that dumps the database — via SQL injection, misconfigured IAM, or insider access — becomes a full cardholder data exposure with no additional attacker steps. OWASP 2021 A02 (Cryptographic Failures) specifically calls out missing database encryption as a root cause.

Why this severity: High because absence of TDE or column encryption means any database read path — including replicas, snapshots, and developer copies — exposes sensitive data without additional exploitation steps.

An encrypted backup that has never been successfully restored is operationally equivalent to no backup. CWE-311 applies equally to backup files: if the backup encryption key is lost, rotated without updating the backup policy, or the encryption configuration is misconfigured, the backup is unrecoverable — which is a data loss event, not a security win. PCI-DSS 4.0 Req-3.4 and NIST SC-28 require that encrypted backups remain recoverable, not just encrypted. FFIEC IT Handbook (Information Security) mandates periodic backup testing. A 180-day verification cadence ensures that rotation events and configuration drift haven't silently broken your recovery path before an incident forces you to find out.

Why this severity: Medium because unencrypted or unverified backups create a secondary exposure vector that is often overlooked until a recovery scenario reveals the gap.

NIST SC-12 requires that cryptographic key establishment and management procedures survive personnel and infrastructure changes. If the encryption key backup procedure exists only in one engineer's head — or in a document that has never been tested — a key loss event during an incident becomes unrecoverable data loss on top of the original incident. PCI-DSS 4.0 Req-3.7 requires key custodian procedures and documented key lifecycle controls. The FFIEC IT Handbook Business Continuity Planning section explicitly requires disaster recovery procedures be tested, not just documented. An untested DR procedure is a hypothesis, not a control.

Why this severity: Low because key DR failures surface only during compound disaster scenarios, but when they occur, the impact is permanent data loss rather than a recoverable security event.

CWE-319 (cleartext transmission of sensitive information) is the direct consequence of missing or misconfigured TLS. Any financial data transmitted over HTTP — payment amounts, account identifiers, session tokens — can be intercepted by a network attacker via passive sniffing or active MITM without the user's knowledge. PCI-DSS 4.0 Req-4.2 explicitly forbids transmission of cardholder data over open public networks without strong cryptography, and specifically deprecates TLS 1.0 and 1.1. NIST SC-8 requires transmission confidentiality. A single HTTP payment API call, even in a test code path that reaches production, is a critical compliance and security failure under both frameworks.

Why this severity: Critical because TLS below 1.2 or missing HTTPS redirects expose financial data to passive network interception with no attacker authentication required — the attack is trivially automated.

CWE-295 (improper certificate validation) and CWE-319 (cleartext transmission) both apply when `rejectUnauthorized: false` is set on payment processor connections. This flag tells Node.js to accept any certificate — including expired, self-signed, or attacker-controlled certificates — making TLS meaningless. An attacker positioned between your server and the payment processor can intercept payment requests, capture API keys, and manipulate transaction amounts without detection. PCI-DSS 4.0 Req-4.2 requires that cardholder data be protected during transmission, which presupposes that the TLS certificate chain is actually verified. NIST SC-8 reinforces this. This vulnerability is commonly introduced as a development workaround and accidentally shipped to production.

Why this severity: High because a single `rejectUnauthorized: false` in a payment API call completely nullifies TLS and enables undetectable MITM attacks against financial transactions.

CWE-522 (insufficiently protected credentials) and CWE-319 overlap when API keys appear in URLs: query string parameters are logged by every proxy, CDN, load balancer, and browser history along the full request path. A Stripe secret key in a URL like `/api/charge?key=sk_live_...` is exposed in server access logs, Cloudflare logs, and any third-party request inspector — long after the original request. PCI-DSS 4.0 Req-4.2 requires that authentication credentials transmitted during payment flows be protected; URL-embedded keys violate this by design. Even a brief window where a key is logged gives an attacker with log access the ability to drain the account or create fraudulent charges.

Why this severity: Medium because URL-embedded API keys are exposed in logs and browser history, but exploitation requires log access or a compromised intermediary rather than direct network interception.

CWE-321 (use of hard-coded cryptographic key) describes the failure where the key and the data it protects are co-located — making the key trivially recoverable from anyone who can read the codebase, a git history export, or an environment variable committed to source control. NIST SC-12 requires that cryptographic keys be generated, distributed, stored, and destroyed through a formal key management process. PCI-DSS 4.0 Req-3.7 requires split knowledge and dual control for key custodianship. An encryption key stored next to the data it encrypts — whether in a `.env` committed to git, `config/keys.json`, or hardcoded in source — means any code read gives an attacker both the ciphertext and the key to decrypt it. OWASP 2021 A02 explicitly cites key co-location as a cryptographic failure root cause.

Why this severity: High because a key stored alongside encrypted data completely defeats encryption — any attacker with codebase read access can decrypt all protected records without brute force.

CWE-324 (use of a key past its expiration date) describes the accumulating risk of long-lived keys: the longer a key is in use, the more ciphertext an attacker accumulates to attempt cryptanalysis against, and the longer a previously undetected key compromise remains exploitable. NIST SP 800-57 Part 1 sets maximum key usage periods; for symmetric keys protecting sensitive data, annual rotation is the established upper bound. PCI-DSS 4.0 Req-3.7.4 explicitly requires cryptoperiod management for encryption keys. An unrotated key that was compromised six months ago continues to expose all data encrypted since the compromise — rotation limits the blast radius of any past key exposure.

Why this severity: High because a stale encryption key that was silently compromised continues to expose all protected data indefinitely until rotation occurs, with no observable signal of the ongoing breach.

CWE-327 (use of a broken or risky cryptographic algorithm) is the direct consequence of algorithm selection without documented justification: teams inherit code using MD5 for hashing or AES-128 for encryption without realizing these are deprecated or insufficient for financial data contexts. NIST SP 800-131A defines algorithm transitions and deprecation timelines; NIST SC-13 requires approved cryptographic modules for protecting federal (and by extension, regulated financial) data. MD5 and SHA-1 are computationally broken for collision resistance; AES-128 is below the PCI-DSS 4.0 key strength floor for new implementations. Undocumented algorithm choices also block compliance auditors — a QSA cannot approve encryption that has no justification trail.

Why this severity: High because undocumented or deprecated algorithm choices (MD5, SHA-1, AES-128 for new implementations) leave the system vulnerable to known cryptanalytic attacks and fail PCI-DSS QSA review.

NIST SC-12 requires key management procedures, which include auditability of key access — knowing who accessed which key and when is the mechanism for detecting insider threats and key compromise. NIST AU-2 requires auditable events to include security-relevant actions; key decryption operations are among the highest-value events in a financial system. PCI-DSS 4.0 Req-10.2 requires logging of all individual user access to cardholder data. Without quarterly review of key access logs, a compromised service account silently decrypting all stored cardholder data goes undetected for months. The FFIEC IT Handbook Audit section explicitly requires periodic review of access to cryptographic systems.

Why this severity: Medium because unreviewed key access logs allow insider abuse or credential-based key compromise to go undetected for extended periods, expanding the breach window.

PCI-DSS 4.0 Req-3.5 requires that primary account numbers (PANs) stored anywhere be protected with strong cryptography. Without documentation stating the algorithm and key length, a QSA cannot verify compliance — and organizations that delegate card processing to Stripe must still document that delegation explicitly with the processor's PCI certification level. NIST SC-13 requires that cryptographic module usage be documented and approved. A vague security policy that says "we use encryption" fails both standards: the specific algorithm, key length, and applicable data scope must be named. FFIEC examiners reviewing a financial institution's IT controls will request this documentation as a baseline artifact.

Why this severity: Medium because absent or vague PCI-DSS encryption documentation fails compliance audits even when the underlying implementation is sound, creating regulatory exposure independent of technical posture.

CWE-326 (inadequate encryption strength) can exist in a system that is technically configured for AES-256 but is serving weak cipher suites due to misconfiguration — a condition only detectable by external TLS scanning, not by reading configuration files. PCI-DSS 4.0 Req-4.2 requires that the actual transmitted encryption meet the standard, not just that the configuration claims to. NIST SC-13 requires approved cryptographic module use. A TLS scan with grade C or lower indicates negotiation of weak cipher suites (RC4, 3DES, export ciphers) that can be exploited by BEAST, POODLE, or SWEET32 attacks against financial transaction traffic. Self-reported TLS configuration is not a substitute for external verification.

Why this severity: Low because scan verification is an operational quality gate — the underlying TLS misconfiguration is the critical issue, and this check measures whether you've confirmed actual cipher strength externally.

CWE-532 (insertion of sensitive information into log files) directly applies when account numbers, SSNs, or email addresses appear in application logs. Financial application logs are typically stored in cloud logging services (CloudWatch, Datadog, Splunk) with broader access than the production database — developers, support staff, and contractors may all have log read access without needing database access. PCI-DSS 4.0 Req-3.3 explicitly prohibits storing sensitive authentication data after authorization. OWASP 2021 A09 (Security Logging and Monitoring Failures) includes inadequate log sanitization. A single `console.log(transaction)` that dumps the full transaction object will log account numbers in plaintext to every log aggregator in the pipeline.

Why this severity: Low severity at this check level because PII in logs requires log access to exploit, but the compliance impact is equivalent to a data exposure event under PCI-DSS and most state breach notification laws.

PCI-DSS 4.0 Req-12.3 requires organizations to document their cryptographic inventory — which algorithms are in use, where, and with what key lengths. NIST SC-13 requires documentation of approved cryptographic modules. Without this documentation, compliance auditors (QSAs, FFIEC examiners) cannot verify that encryption meets the required standards, and internal teams cannot make informed decisions when upgrading or rotating algorithms. A `SECURITY.md` that says "we encrypt sensitive data" without naming the algorithm or key length cannot satisfy either framework. Documentation gaps also create drift risk: without a written spec, different developers may implement different algorithms across services.

Why this severity: Low because missing documentation is an audit and governance failure rather than an active exploit path, but it blocks PCI-DSS QSA approval and creates conditions for algorithm drift.

Financial services have latency SLAs that encryption operations must fit within. Application-level field encryption in Node.js, if implemented naively (synchronous crypto in request handlers, per-field key derivation on every read), can add hundreds of milliseconds to database read paths — degrading payment confirmation UX and potentially triggering timeout-based retry loops that amplify costs. ISO 25010 performance-efficiency requirements apply to cryptographic subsystems as much as to application code. If encryption overhead pushes p99 latency above payment processor timeout thresholds, the fallback logic (retries, error responses) can itself create inconsistent transaction states.

Why this severity: Low because performance impact from encryption is rarely catastrophic, but unquantified overhead creates invisible latency budgets that compound under load and cause subtle SLA violations.

CWE-321 (hard-coded cryptographic key) covers key reuse across environments as much as literal key embedding: when dev and prod share an encryption key, a developer database compromise — a much lower-bar attacker target — exposes the key that also decrypts production data. NIST SC-12 requires that key management procedures account for environment lifecycle boundaries. Cross-environment key sharing also violates the broader key-management lifecycle expectations in PCI-DSS v4.0 Requirement 3.7 — dev/prod key separation is the only way trust boundaries remain meaningful under those procedures. Environment-specific keys constrain the blast radius of a dev credential compromise to the dev environment only.

Why this severity: Low because exploiting shared keys requires developer credential access in addition to database access, but the control gap converts a dev breach into a prod data exposure.

CWE-1357 (reliance on insufficiently trustworthy component) applies directly to floating version constraints on cryptographic libraries: `crypto-js@^4.1.0` will silently upgrade to a version containing vulnerabilities or breaking changes during a routine `npm install`. PCI-DSS 4.0 Req-6.3 requires that security vulnerabilities in all system components be identified and protected — floating deps undermine this by allowing unvetted code into the cryptographic layer without a code review or security audit. SLSA L2 and SSDF PW.4 both require pinned, audited dependencies for supply chain integrity. A compromised crypto library release — even for 24 hours before detection — can backdoor encryption for all data processed during that window.

Why this severity: Info because floating crypto library versions introduce supply chain risk that only manifests during an actual compromised package release, but the control gap is a compliance finding under PCI-DSS Req-6.3.

PCI-DSS 4.0 Req-12.3 requires that security controls be formally reviewed before deployment to cardholder data environments. NIST CA-6 requires authorization of information system operation — the ATO (Authority to Operate) concept applied to encryption controls. An encryption checklist with sign-off is the artifact that proves this review occurred; without it, every production deployment is an unreviewed change to the cardholder data environment. FFIEC IT Handbook Information Security procedures explicitly require pre-deployment review gates. A checklist without a sign-off record is indistinguishable from a checklist that was never reviewed — the dated signature is the control, not the document itself.

Why this severity: Info because missing pre-deployment sign-off is a process control gap rather than a technical vulnerability, but it creates audit findings and means encryption changes ship without formal review.

CWE-311 applies to legacy data as much as to new records: financial systems that added encryption requirements mid-lifecycle often have years of plaintext records in production tables that were never backfilled. PCI-DSS 4.0 Req-3.4 requires that stored PANs be unreadable anywhere they are stored — legacy records are not exempt. NIST SC-28 requires confidentiality of information at rest regardless of when it was written. A re-encryption plan with 0% progress means the encryption controls that apply to new records do not protect the existing dataset, which is typically the most valuable target for attackers exfiltrating historical financial data. Without a tracked migration plan, legacy exposure compounds with every passing month.

Why this severity: Info because legacy data without a re-encryption plan is an inherited technical debt gap rather than an active development defect, but it represents a compliance scope gap under PCI-DSS Req-3.4 that cannot be waived.