Security Checklists

The Top 10 was re-issued in 2025 and replaces the 2021 edition. Two categories are brand new (A03, A10) and SSRF has been absorbed into A01 — if a checklist you are using still lists SSRF separately, it is out of date.

• A01Broken Access ControlEvery object reference is authorised server-side, not just hidden in the UI. Includes SSRF, which folded into A01 in 2025.
• A02Security MisconfigurationDefault credentials removed, admin panels not exposed, debug off, security headers set, cloud storage not public. Biggest riser in 2025.
• A03Software Supply Chain FailuresDependencies pinned and verified, SBOM produced, build pipeline and release tokens protected. New category in 2025.
• A04Cryptographic FailuresTLS enforced, no weak/legacy ciphers, secrets not hardcoded, data at rest encrypted, passwords hashed with a modern KDF.
• A05InjectionAll queries parameterised; output encoded per context. XSS lives here, not in its own category.
• A06Insecure DesignThreat model exists. Abuse cases and business-logic limits are designed in, not bolted on.
• A07Authentication FailuresMFA available, credential stuffing throttled, session IDs rotated on login, no user enumeration.
• A08Software or Data Integrity FailuresNo unsigned updates, no unsafe deserialisation, CI/CD cannot be poisoned by an untrusted contributor.
• A09Security Logging and Alerting FailuresAuth events, access failures and admin actions are logged, shipped off-host, and someone is actually alerted.
• A10Mishandling of Exceptional ConditionsErrors fail closed, not open. No stack traces to users. Edge cases and nulls do not bypass a control. New in 2025.

Still the current edition as of July 2026 — there is no 2025/2026 API list. Six of the ten involve technically valid requests from a real, authenticated user, which is exactly why scanners miss them.

• API1Broken Object Level Authorization (BOLA)Every object ID in a request is checked against the caller's ownership. Ranked #1 since 2019.
• API2Broken AuthenticationToken signature, expiry and audience all validated. No 'alg: none'. Refresh tokens revocable.
• API3Broken Object Property Level AuthorizationNo mass assignment; responses do not over-expose fields and let the client filter.
• API4Unrestricted Resource ConsumptionRate limits, payload size caps, pagination limits, and cost ceilings on expensive endpoints.
• API5Broken Function Level AuthorizationAdmin functions are not reachable just by guessing the route or changing the HTTP verb.
• API6Unrestricted Access to Sensitive Business FlowsPurchase / booking / signup flows are protected against automated abuse at scale, not just against 'bugs'.
• API7Server Side Request ForgeryURLs supplied by clients are validated against an allowlist; no access to cloud metadata endpoints.
• API8Security MisconfigurationCORS not wildcarded with credentials, verbose errors off, TLS enforced, unused verbs disabled.
• API9Improper Inventory ManagementNo forgotten /v1 next to /v3. Every environment and every host is inventoried.
• API10Unsafe Consumption of APIsData from third-party APIs is validated as carefully as data from users.

MASVS v2 is category-based — the old L1/L2 verification levels are gone; risk tiering now lives in the MASTG as testing profiles (MAS-L1, MAS-L2, MAS-R). MASVS is the requirement, MASTG is the test.

• STORAGESensitive data storageNo secrets, tokens or PII in plaintext prefs, SQLite, logs, or backups.
• CRYPTOCryptographyPlatform keystore used; no hardcoded keys; no home-rolled crypto.
• AUTHAuthentication & authorisationAuth enforced server-side. Biometric unlock gates a keystore-bound key, not just a UI screen.
• NETWORKNetwork communicationTLS enforced, certificate validation not disabled in release builds, pinning where warranted.
• PLATFORMPlatform interactionExported components locked down, deep links validated, WebView JS bridges not exposing native calls.
• CODECode qualityDependencies current, no debug code shipped, input from IPC/intents validated.
• RESILIENCEResilience against reverse engineeringAnti-tamper / root-jailbreak detection appropriate to the risk tier (MAS-R).
• PRIVACYPrivacyData collection minimised and declared; the 8th category, added in v2.1.0.

The 2025 edition added System Prompt Leakage and Vector & Embedding Weaknesses, and rewrote Excessive Agency for real agent products. Treat it as a coverage map, not a tick-box list: prompt injection has no known complete fix, so the control has to be architectural.

• LLM01Prompt InjectionDirect, indirect (via retrieved docs/web/email) and multimodal injection tested. Untrusted content is never trusted as instructions.
• LLM02Sensitive Information DisclosureThe model cannot be talked into revealing secrets, other users' data, or training data.
• LLM03Supply ChainModel weights, datasets, plugins and packages are from verified sources; no unsafe pickle deserialisation.
• LLM04Data and Model PoisoningTraining / fine-tuning / embedding data is trusted and integrity-checked.
• LLM05Improper Output HandlingModel output is never passed unvalidated to a shell, SQL query, browser, or HTTP client.
• LLM06Excessive AgencyThe agent's tools, permissions and autonomy are the minimum its job needs. Human-in-the-loop on destructive actions.
• LLM07System Prompt LeakageNo secrets or authorisation logic in the system prompt — assume it will be extracted.
• LLM08Vector and Embedding WeaknessesRAG store is protected against poisoning and cross-tenant retrieval leakage.
• LLM09MisinformationDownstream systems do not act on unverified model claims.
• LLM10Unbounded ConsumptionRate limits and cost ceilings — denial-of-wallet is a real availability risk.

Cloud breaches are overwhelmingly misconfiguration, not exploitation. Map to the CIS Benchmark for your provider and treat drift as an incident.

• C1Identity & accessNo long-lived static keys. MFA on every human account. Roles scoped least-privilege.
• C2Non-human identity inventoryService accounts, CI tokens and OAuth grants are inventoried and rotated. This is how the 2026 supply-chain breaches happened.
• C3Public exposureNo public buckets, no databases on 0.0.0.0/0, no management ports open to the internet.
• C4Secrets managementNo credentials in repositories, images, or environment dumps. A secret manager is used.
• C5EncryptionAt rest and in transit, with customer-managed keys where the data warrants it.
• C6Logging & detectionCloudTrail/equivalent on in every region, immutable, and alerting to somebody.
• C7Network segmentationBlast radius contained. Workloads cannot reach each other by default.
• C8Metadata serviceIMDSv2 (or equivalent) enforced — this is the SSRF-to-cloud-takeover path.

The goal is not a clean scan. The goal is that a single foothold cannot become domain compromise.

• N1Asset inventoryYou know what is exposed. Shadow IT is found before an attacker finds it.
• N2External attack surfaceOnly the services that must be internet-facing are internet-facing.
• N3Patch managementInternet-facing and known-exploited (KEV) vulnerabilities are prioritised over raw CVSS.
• N4Active Directory hardeningNo unconstrained delegation, no Kerberoastable service accounts with weak passwords, tiered admin model.
• N5SegmentationFlat networks are the single biggest force multiplier for ransomware.
• N6Credential hygieneNo shared local admin passwords (LAPS or equivalent). No passwords in scripts or GPOs.
• N7BackupsOffline or immutable, and — critically — restore-tested.
• N8Detection & responseEDR deployed everywhere, and a runbook that has actually been rehearsed.

A scanner reads syntax. A reviewer reads intent — which is why business-logic and authorisation flaws only fall out of manual review.

• R1Authorisation logicChecked at every entry point, server-side, and centrally — not copy-pasted per controller.
• R2Input handlingParameterised queries everywhere. Context-correct output encoding.
• R3SecretsNo keys, tokens or passwords in source, history, or config committed to the repo.
• R4DependenciesSCA in CI; known-vulnerable and unmaintained packages flagged; lockfiles committed.
• R5CryptographyStandard libraries only. Correct modes, correct IV handling, no ECB.
• R6Error handlingFails closed. No sensitive detail in messages returned to the user (A10:2025).
• R7Business logicRace conditions, negative quantities, price/qty tampering, workflow step-skipping.
• R8CI/CD integrityA pull request from a fork cannot exfiltrate a release token (A03/A08:2025).

Auditors do not accept a scanner PDF. They accept scoped, dated, methodology-referenced evidence with a retest showing closure.

• K1Scope definedYou can draw the boundary of what is in scope and defend it.
• K2Risk assessmentDocumented, current, and it actually drives your control choices.
• K3Statement of ApplicabilityEvery Annex A control is included or excluded with a stated reason (ISO 27001).
• K4Policies liveApproved, versioned, communicated — not written the week before the audit.
• K5Access reviewsPerformed on a schedule, with evidence of the review and of the removals.
• K6Vendor / third-party riskYou know which vendors hold which regulated data. 2026's breaches came through vendors.
• K7Pentest evidenceIndependent, scoped, in-date, with findings tracked to closure and a retest.
• K8Incident responseDocumented, assigned, and exercised — with dated evidence of the exercise.