Every FISMA/FedRAMP Readiness Audit check

Transmitting credentials over unencrypted HTTP exposes every login, password-reset token, and OAuth callback to network interception — a passive attacker on the same Wi-Fi can harvest session tokens in seconds. NIST 800-53 rev5 SC-8 (Transmission Confidentiality) and SC-23 (Session Authenticity) require cryptographic protection for all in-transit data; FedRAMP rev5 makes this a hard requirement for cloud systems handling federal data. CWE-319 and OWASP A02 (Cryptographic Failures) both cite cleartext credential transmission as a direct path to account takeover. Without HSTS, even an HTTPS-capable server remains vulnerable to SSL stripping during the first unprotected request.

Why this severity: Critical because unencrypted authentication transport lets any passive network observer capture credentials and session tokens without any active exploit.

A hardcoded secret in source code is immediately compromised the moment the repository is cloned, forked, or accidentally made public — and Git history preserves it even after deletion. NIST 800-53 rev5 IA-5 (Authenticator Management) prohibits embedding authenticators in code, and SC-28 requires protection of information at rest including stored credentials. CWE-798 covers this exact failure; OWASP A07 (Identification and Authentication Failures) lists hardcoded credentials as a primary cause of large-scale breaches. A single leaked Stripe live key or database password is sufficient to exfiltrate all user data or drain financial accounts.

Why this severity: Critical because a hardcoded secret in any committed file immediately grants adversaries full access to whatever service the credential controls, requiring no further exploitation.

Weak password requirements are the primary enabler of credential-stuffing attacks: attackers replay breached credential lists at scale and succeed wherever short or trivially guessable passwords are allowed. NIST 800-63B and NIST 800-53 rev5 IA-5(1) mandate a minimum of 8 characters (NIST guidance recommends 12+) with complexity requirements, and AC-7 requires rate-limiting after repeated failed authentication attempts. CWE-521 (Weak Password Requirements) and OWASP A07 both rank this as a systemic authentication failure. Client-only validation is bypassed by any direct API call, so server-side enforcement is non-negotiable.

Why this severity: High because weak or unrate-limited password endpoints are the direct entry point for automated credential-stuffing and brute-force campaigns targeting every user account.

Password-only admin access means one phished or brute-forced credential hands an attacker complete administrative control. PCI DSS 4.0 Requirements 8.4 and 8.5 mandate multi-factor authentication for all access to the Cardholder Data Environment; NIST 800-53 rev5 IA-2(1) and IA-2(2) require MFA for privileged accounts. CWE-308 (Use of Single-Factor Authentication) and OWASP A07 both list missing MFA as a primary cause of privileged account compromise. A stolen admin password without a second factor exposes every user record, payment record, and configuration secret in the system.

Why this severity: High because admin account compromise via password alone escalates immediately to full data breach; MFA is the primary control preventing lateral movement from a single credential leak.

Without role-based access control, every authenticated user has the same permissions as an administrator — a regular user can delete records, reassign roles, or exfiltrate all data through unguarded API endpoints. NIST 800-53 rev5 AC-2 (Account Management) requires formal role definitions, and AC-6 (Least Privilege) mandates that users receive only the minimum access required for their function. CWE-285 (Improper Authorization) and OWASP A01 (Broken Access Control) consistently rank this as the most exploited web application vulnerability. Frontend-only role gates are bypassed by any direct API call using the browser's developer tools.

Why this severity: High because absent server-side permission checks allow any authenticated user to perform privileged operations simply by calling the API directly, bypassing every UI-level guard.

Indefinite sessions leave authenticated tokens valid on shared or stolen devices long after the user leaves — a session cookie captured from an unattended workstation grants full account access with no expiry. NIST 800-53 rev5 AC-12 (Session Termination) requires automatic logout after inactivity, and AC-11 mandates re-authentication before sensitive operations. CWE-613 (Insufficient Session Expiration) and OWASP A07 both cite missing session timeouts as enabling session hijacking attacks. Federal system guidance caps inactivity timeout at 30 minutes; operations like password changes require step-up authentication even within an active session.

Why this severity: Medium because indefinite sessions enable session hijacking from unattended devices but require an attacker to already possess a valid token — exploitation is not fully remote.

Distinct error messages for "user not found" versus "wrong password" let an attacker enumerate valid email addresses with a single automated script, turning a minor information leak into a targeted credential-stuffing campaign. NIST 800-53 rev5 SI-11 (Error Handling) prohibits revealing system internals or data states in user-facing messages; AU-3 requires that sensitive detail be captured in server-side logs only. CWE-209 (Information Exposure Through an Error Message) and OWASP A05 (Security Misconfiguration) both flag this as a systematic vulnerability. Database exception strings leaked to the browser also reveal table names, column names, and query structure.

Why this severity: Medium because information-leaking errors aid enumeration and reconnaissance but require attacker interaction with the live system — they do not directly expose data without further exploitation.

Without structured audit logs, there is no forensic record of who accessed sensitive data, who changed permissions, or when an account was compromised — making incident response guesswork and regulatory compliance impossible. NIST 800-53 rev5 AU-2 (Event Logging) defines the minimum event set; AU-3 (Content of Audit Records) mandates user ID, timestamp, event type, and outcome in every record; AU-12 (Audit Record Generation) requires the system to generate these records reliably. CMMC 2.0 AU.L2-3.3.1 and FedRAMP rev5 AU-2 enforce this for any system handling federal or controlled unclassified information. Missing audit trails also violate incident-reporting obligations under many state and federal data breach notification laws.

Why this severity: Medium because the absence of audit logging does not directly cause a breach but eliminates the ability to detect, contain, or legally demonstrate the scope of one after the fact.

Audit logs stored in the same database as application data can be silently deleted or modified by a compromised admin account, eliminating the forensic record of the compromise itself. NIST 800-53 rev5 AU-9 (Protection of Audit Information) requires that log write access be restricted to the audit system only; AU-10 (Non-Repudiation) mandates a mechanism to prove log integrity. CMMC 2.0 AU.L2-3.3.2 extends this requirement to CUI systems. CWE-345 (Insufficient Verification of Data Authenticity) covers the specific failure of storing records without integrity protection. An attacker who can modify logs can rewrite or delete evidence of their own access.

Why this severity: Medium because tamper-evident logging does not prevent breaches but is required to detect them and preserve legally admissible forensic evidence — its absence is often discovered only during post-breach investigation.

Unpatched dependencies are the most common initial access vector in supply-chain attacks: a single vulnerable `lodash` or `express` version can expose every application built with it once a public exploit drops. NIST 800-53 rev5 SI-2 (Flaw Remediation) requires timely patching; RA-5 (Vulnerability Monitoring and Scanning) mandates continuous scanning. FedRAMP rev5 SI-2 sets a 30-day remediation window for high-severity findings. CWE-1357 and SLSA L2 both address dependency provenance and vulnerability management. CI/CD pipelines that never run `npm audit` provide a false sense of security — vulnerabilities accumulate silently across every merge.

Why this severity: Low because known dependency vulnerabilities require a secondary exploit path specific to how the library is used, but they represent pre-positioned risk that attackers target at scale.

User input that flows directly into a database query, HTML output, or LDAP filter without server-side validation is the root cause of SQL injection, stored XSS, and LDAP injection — three of the most consistently exploited vulnerability classes. NIST 800-53 rev5 SI-10 (Information Input Validation) requires validation of all inputs for type, length, format, and range; SC-18 restricts execution of mobile or untrusted code. FedRAMP rev5 SI-10 applies to all federal cloud systems. CWE-89 (SQL Injection) and OWASP A03 (Injection) have appeared in every OWASP Top 10 since its inception. A single unvalidated search field in a Prisma raw query is sufficient to dump the entire database.

Why this severity: High because unvalidated input directly enables injection attacks that can exfiltrate or destroy all database contents without requiring any additional privileges.

Missing security headers leave browsers without the instructions needed to block clickjacking, MIME-type sniffing attacks, and content injection — gaps that attackers exploit through iframe embeds, malicious redirects, and injected scripts. NIST 800-53 rev5 SC-8 covers transmission integrity and SI-3 covers malicious code protection; both are satisfied in part by response headers that tell browsers what to trust. FedRAMP rev5 SC-8 applies to all cloud systems serving federal users. OWASP A05 (Security Misconfiguration) and CWE-693 (Protection Mechanism Failure) specifically call out absent security headers. A CSP header alone can neutralize most XSS payloads that slip through input validation.

Why this severity: High because absent security headers expose every page visitor to clickjacking, MIME-confusion exploits, and reflected XSS attacks that require no server-side vulnerability to execute.

Undocumented account provisioning means departing employees retain access indefinitely and new joiners receive inconsistent permissions — two direct violations of NIST 800-53 rev5 AC-2 (Account Management), which requires formal procedures for account creation, modification, review, and termination. CMMC 2.0 AC.L1-3.1.1 makes this a baseline requirement for any contractor handling federal information. FedRAMP rev5 AC-2 adds an auditable trail requirement. Without documented deprovisioning steps, a disgruntled ex-employee's credentials may remain valid long after their last day, and an auditor will flag the absence of written procedures as a control gap regardless of what the code does.

Why this severity: Low because undocumented provisioning does not directly enable an attack, but its absence means deprovisioning failures go undetected and auditors will cite it as a control deficiency.

Unencrypted data at rest is accessible to anyone with storage access — a misconfigured S3 bucket, a stolen database volume, or a compromised hosting account exposes every user record without any additional decryption step. NIST 800-53 rev5 SC-28 (Protection of Information at Rest) requires encryption for sensitive data in storage; SC-8 covers transit encryption; IA-5(1) specifically requires password hashing with approved algorithms. FedRAMP rev5 SC-28 applies to all CUI and federal data stored in cloud systems. CWE-311 (Missing Encryption of Sensitive Data) covers both cases. MD5 and SHA-1 password hashing are broken — bcrypt and Argon2 remain the approved choices.

Why this severity: Low in this audit context because verifying encryption relies partly on documentation and provider configuration rather than direct code inspection, but the underlying risk of plaintext data exposure is severe.

A missing privacy policy is not just an oversight — it is a legal violation under GDPR Article 13 (disclosure at point of collection), CCPA §1798.100 (right to know), and NIST 800-53 rev5 PT-1 (Privacy Policies, Agreements, and Processing). FedRAMP rev5 PT-1 requires agencies and their cloud providers to maintain and publish privacy notices. Users have no way to exercise data access, correction, or deletion rights without a published policy describing those rights. Regulators in California and the EU routinely issue fines for absent or incomplete policies even when no breach has occurred.

Why this severity: Low as a code-level severity because the absence of a privacy policy does not create a technical exploit path, but the legal and regulatory exposure is material and enforcement is routine.

Without a written incident response plan, a security breach becomes an improvised crisis: response teams disagree on escalation paths, evidence is destroyed before it is preserved, and affected users receive notifications too late to take protective action. NIST 800-53 rev5 IR-8 (Incident Response Plan) requires a documented, tested response plan; IR-4 (Incident Handling) requires detection, analysis, containment, and recovery procedures. CMMC 2.0 IR.L2-3.6.1 and FedRAMP rev5 IR-8 both make this a mandatory control. Most state breach notification laws impose 72-hour or shorter notification windows — a team with no rehearsed plan routinely misses them.

Why this severity: Low as a code-level control because the absence of documentation does not cause a breach, but it guarantees that response to any breach will be slower and more damaging than it needs to be.

Without a `security.txt` file, security researchers who discover a vulnerability in your system have no official channel to report it responsibly — so they either publish publicly or simply move on. NIST 800-53 rev5 SI-5 (Security Alerts, Advisories, and Directives) and IR-6 (Incident Reporting) require systems to have mechanisms for receiving security information; FedRAMP rev5 IR-6 extends this to cloud providers. RFC 9116 formalizes `security.txt` as the standard machine-readable disclosure policy. Government procurement increasingly requires a published vulnerability disclosure policy as a condition of contract. A missing file does not stop researchers from finding issues — it stops them from telling you.

Why this severity: Info because an absent security.txt does not directly increase attack surface, but it removes the primary responsible-disclosure channel and signals to evaluators that a vulnerability disclosure policy may be absent entirely.

Systems without documented backup and recovery procedures lose data permanently when hardware fails, ransomware encrypts a database, or a destructive migration runs on production. NIST 800-53 rev5 CP-9 (System Backup) requires defined backup frequencies, storage locations, and verification procedures; CP-10 (System Recovery and Reconstitution) mandates documented recovery steps and tested restoration. CMMC 2.0 RE.L2-3.8.9 requires regular backups of CUI. FedRAMP rev5 CP-9 sets specific requirements for backup retention and off-site storage. Without a written RTO and RPO, teams discover their actual recovery time during an outage — typically far longer than stakeholders expect.

Why this severity: Low because inadequate backup documentation does not increase the likelihood of data loss directly, but guarantees longer downtime and greater data loss when any loss event occurs.

Federal compliance without a roadmap is aspirational rather than actionable — developers patch individual findings without understanding which controls feed into ATO (Authority to Operate), which gaps block a FedRAMP assessment, or in what sequence remediation should proceed. NIST 800-53 rev5 PL-2 (System Security Plan) requires a documented security plan with milestones; CA-2 (Control Assessments) requires planned assessment cycles. FedRAMP rev5 PL-2 gates the authorization process on a compliant System Security Plan (SSP). Without a roadmap, audit findings pile up in a backlog with no prioritization framework, and federal procurement windows close before the system reaches assessable maturity.

Why this severity: Info because a missing roadmap does not introduce a technical vulnerability, but its absence means remediation is reactive and uncoordinated — audit findings accumulate without a path to authorization.

Without a continuous monitoring plan, security controls degrade silently after initial deployment: certificates expire, dependency vulnerabilities accumulate, access logs fill with anomalies no one reviews, and permission creep goes undetected. NIST 800-53 rev5 CA-7 (Continuous Monitoring) is a cornerstone FISMA control that requires defined monitoring frequency, event types, and review schedules; AU-6 (Audit Record Review, Analysis, and Reporting) mandates regular review of audit logs. FedRAMP rev5 CA-7 requires monthly vulnerability scans and annual penetration testing with documented results. CMMC 2.0 CA.L2-3.12.3 mandates a continuous monitoring strategy. A security posture that was compliant at ATO can drift out of compliance within weeks without a documented monitoring cadence.

Why this severity: Info because an undocumented monitoring plan does not introduce a new vulnerability but guarantees that existing controls erode undetected — an assessor will cite its absence as a CA-7 control deficiency.