TL;DR
- CASA (Cloud Application Security Assessment) is the App Defense Alliance (ADA) certification scheme for web applications and web-accessible APIs, now maintained by the ASA Working Group and built on OWASP ASVS.
- Two assurance levels: AL1 (Verified Self-Assessment) — the developer submits evidence and compliance statements for every audit test case, including required automated scan artifacts, and an ADA-approved lab reviews that evidence without directly testing the app. AL2 (Lab Assessment) — the lab evaluates every audit test case directly against the running application, with the developer providing limited supporting information or code snippets on request.
- CASA is organized into six control domains: Authentication, Session Management, Access Control (including OAuth 2.0), Communications (TLS/crypto), Data Validation and Sanitization, and Configuration.
- Scoping determines which first-party components and third-party APIs handling sensitive operations (auth, user data mutation, account recovery) fall inside the assessment boundary — this is usually the single biggest source of quote and timeline disputes.
- A CASA assessment does not replace a full penetration test, a secure SDLC, or privacy compliance — it verifies a defined, testable subset of OWASP ASVS-aligned controls.
- ValueMentor is pursuing/holds ADA Authorized Lab status for the applicable CASA profile — verify current listing status before publication — and runs assessor-led scoping, evidence-pack review, and certification-submission support for both AL1 and AL2 engagements.
Not sure whether your last web pentest actually maps to CASA’s audit test cases? Book a 30-minute CASA scoping call and get a preliminary breakdown of which of your existing evidence (SAST/DAST reports, pentest findings, config baselines) already satisfies specific CASA controls versus what still needs to be generated.
Introduction
Most engineering teams don’t worry about security until someone asks a simple question:
“Can you prove your application is secure?” That’s when the real challenge begins.
You may have penetration test reports, vulnerability scans, secure coding practices, and months of remediation work behind you. But when a platform, customer, or business partner asks for evidence that your web application or API meets a recognized security standard, scattered reports and security claims are rarely enough.
This is exactly where CASA comes in. Instead of asking whether you’ve “done security,” CASA asks whether you can demonstrate it through measurable controls, verifiable evidence, and a standardized assessment process.
In this guide, we will break down what CASA certification really means, how AL1 and AL2 assessments differ, the controls that matter most, and how your team can prepare without turning the assessment into a last-minute scramble.
What CASA Actually Certifies (and What It Doesn’t)
CASA — formally the ADA Web/API security profile, previously published as the ADA Web App Profile and before that as CASA v2 — defines testable, acceptance-criteria-driven requirements derived from OWASP ASVS. The working group’s explicit design goal was automation-friendly, binary-outcome test cases rather than broad advisory guidance. That’s why every control below maps to a specific Spec ID with a pass/fail audit statement, not a narrative recommendation.
What’s in scope by default:
- The target web application(s) as a logical service group, plus shared first-party backend components/APIs they depend on.
- Third-party product APIs that perform sensitive operations — authentication, user data access/mutation, account recovery — but only against the Authentication, Session Management, and Access Control requirements, and only for the components/configurations your application actually uses.
What’s explicitly out of scope:
- Third-party APIs your application doesn’t call.
- Non-sensitive operations on third-party APIs (e.g., an analytics ingestion endpoint that never touches user data).
- Full penetration testing outside the ASVS-aligned control set, general secure SDLC maturity, and privacy/regulatory compliance (GDPR, CCPA, etc.) — CASA doesn’t attest to any of these.
AL1 vs. AL2: What Actually Changes Operationally
| AL1 — Verified Self-Assessment | AL2 — Lab Assessment | |
| Who tests the app | You do, against each audit test case | The ADA-approved lab, directly |
| What the lab does | Reviews your submitted evidence and compliance statements per test case | Independently executes/validates each test case against the live application |
| Evidence burden | You must produce a verified self-assessment package: automated scan artifacts, configuration exports, and documented compliance statements for every Spec ID | You provide the app, environment access, and limited supporting artifacts or code snippets only where the lab requests them |
| Typical trigger | Platform or partner requirement for a lighter-weight, evidence-based attestation | Higher-risk applications, platform requirements mandating an Authorized Security Testing Lab (ASTL), or when self-assessment evidence can’t be independently substantiated |
The distinction that trips up engineering teams: AL1 is not “paperwork only.” It requires the same automated scan coverage (SAST/DAST/dependency scanning outputs) that would inform AL2 — the difference is who executes the live verification against the application, not whether technical evidence is required at all.
CASA Control Domains, Audit Test Cases, and Assessment Evidence
The table below maps each CASA control area to the actual Spec IDs from the current specification, what an assessor does at each one, and what typically fails in practice.
| Assessment area | Relevant requirement or control | What the assessor tests or reviews | Evidence the development team should provide | Common failure pattern | Recommended pre-assessment action |
| Authentication | 1.1 Password security (brute-force resistance, initial-password expiry, offline-attack-resistant storage) | Rate-limiting/lockout behavior under automated credential-stuffing simulation; password hash algorithm and work factor; expiry of system-generated activation codes | SAST/DAST scan output covering auth endpoints; password hashing config (e.g., bcrypt/argon2 parameters); rate-limit/WAF rules | Missing or IP-only rate limiting that’s trivially bypassed with rotating headers or distributed sources | Run an authenticated DAST pass specifically against login/reset endpoints before submission |
| Authentication | 1.2 Default accounts disabled on public interfaces | Attempts default/known credential pairs against publicly exposed login surfaces | Inventory of all public-facing accounts and provisioning workflow documentation | Default admin accounts left active on staging environments that are technically internet-reachable | Run an external attack-surface scan to confirm no forgotten default-credential endpoints are exposed |
| Authentication | 1.3 Out-of-band verifier randomness/reuse (SMS/email OTP) | Entropy and reuse of OTP/verification codes; expiry window; brute-force resistance | OTP generation logic or code snippet; expiry configuration; rate-limit config on the verification endpoint | Predictable or sequential OTPs, or codes that remain valid after first use | Verify OTP generation uses a CSPRNG and enforce single-use + short TTL server-side |
| Session Management | 2.1–2.4 URL exposure of authentication material, logout/expiration invalidation, Secure/HttpOnly cookie flags, re-auth on sensitive actions | Inspects URLs/logs for tokens in query strings; triggers logout/password-change flows and checks token revocation; inspects Set-Cookie headers; attempts sensitive account changes on a stale session | HAR captures or DAST logs showing no tokens in URLs; session invalidation logic; cookie configuration | Refresh tokens that remain valid after logout because only the access token is revoked | Confirm logout invalidates all stateful tokens, including refresh tokens, server-side |
| Access Control | 3.1 Least-privilege access control, IDOR protection, anti-CSRF, secure failure | Systematic IDOR probing (horizontal/vertical privilege escalation) via parameter manipulation; CSRF token validation; error-handling fail states | API access-control matrix; anti-CSRF token implementation; authorization middleware code snippets | Object references (order IDs, user IDs) that are sequential and lack ownership checks server-side | Run an authenticated IDOR sweep across every object-returning endpoint prior to assessment |
| Access Control | 3.2 Secure OAuth 2.0 integrations | Confirms only Authorization Code Flow (with PKCE where applicable) is used; validates `redirect\_uri` allowlisting and `state` parameter enforcement | OAuth flow diagrams; client configuration showing PKCE enablement; redirect URI allowlist | Implicit Flow still enabled for legacy clients, or `redirect\_uri` validated with a loose substring match instead of an exact allowlist match | Migrate any remaining Implicit or Resource Owner Password Credentials flows and lock `redirect\_uri` matching to exact-string allowlists |
| Access Control | 3.3 MFA on exposed administrative interfaces | Attempts access to admin-layer functionality; confirms MFA enforcement and that infrastructure-layer admin is not internet-exposed | Admin interface inventory; MFA enforcement configuration | Application-layer admin panel reachable externally without MFA, distinct from infrastructure console access | Enforce MFA on every internet-reachable admin route and confirm infrastructure consoles are never public |
| Communications | 4.1 TLS configuration, trusted certificates, weak-crypto elimination, secure crypto failure modes | TLS configuration scan (cipher suites, protocol versions); certificate trust chain validation; padding-oracle and weak-cipher testing | Server TLS configuration export; certificate chain documentation; internal CA trust list | Self-signed or internal CA certificates trusted server-wide instead of pinned to specific issuers | Run a TLS configuration scan and restrict trust to explicitly listed internal CAs/certificates |
| Data Validation | 5.1 Injection defenses (XSS, SQLi, OS command injection, SSRF, XPath/XML injection, template injection, HTTP parameter pollution, unsafe eval) | Automated and manual injection testing across all input vectors; output-encoding verification; SSRF probing against internal metadata endpoints | SAST results covering input handling; DAST scan results across all parameters; allowlist configuration for redirects | SSRF via unvalidated outbound requests reaching internal cloud metadata services (e.g., 169.254.169.254) | Add egress allowlisting/validation on any server-side outbound request feature before assessment |
| Data Validation | 5.2 Secure handling of untrusted file uploads | Uploads disallowed file types/extensions; checks for direct execution of uploaded content | File-type allowlist configuration; storage/execution isolation architecture | Uploaded files served from the same origin/path structure that allows execution as server-side or client-side code | Serve uploads from a separate, non-executable origin or object storage with strict content-type enforcement |
| Configuration | 6.1–6.7 Component patching, debug modes, Origin-header trust, subdomain takeover, credential/payment logging, browser storage clearing, secrets management | Dependency/CVE scanning; probes for exposed debug endpoints/stack traces; DNS/CNAME audit for dangling records; log review for sensitive data; browser storage inspection post-logout; secrets-store configuration review | SCA/dependency scan reports; production configuration confirming debug disabled; DNS zone file; log sampling; secrets management architecture (e.g., vault/KMS configuration) | Dangling CNAME records pointing to decommissioned third-party services, enabling subdomain takeover | Run a DNS/CNAME audit against all subdomains and remove or reclaim any pointing to deprovisioned services |
Have an existing pentest report and want to know which rows above it already covers? Send us your latest test summary and we’ll return a gap map showing which CASA Spec IDs are already substantiated versus which need new evidence — before you scope a full engagement.
Testing Methodology: How the Evidence Actually Gets Generated
CASA’s control set assumes automation-first verification wherever a test case can be made binary. In practice, a CASA-aligned technical program layers four testing vectors:
- SAST (Static Application Security Testing) against the application codebase — surfaces injection-prone patterns (unsanitized
eval()usage, unparameterized queries), insecure cryptographic calls, and hardcoded secrets before runtime testing even starts. This directly feeds Spec IDs under 5.1 and 6.7. - DAST (Dynamic Application Security Testing) against a running instance — authenticated and unauthenticated crawl-and-attack passes covering the OWASP ASVS-aligned injection, session, and access-control test cases (2.x, 3.1, 5.1).
- Configuration audits — TLS/cipher suite scanning, DNS/CNAME review for subdomain takeover exposure (6.4), dependency/CVE scanning for outdated components (6.1), and cloud/server hardening checks against baselines consistent with CIS Benchmark guidance.
- Manual verification — IDOR chains, OAuth flow inspection (redirect_uri/state validation), business-logic abuse cases, and anything a scanner can flag but not conclusively confirm — these are the test cases most likely to require AL2-level, hands-on lab execution rather than self-assessment evidence.
Across web/API assessments generally, OAuth
redirect\_urivalidation and session/refresh-token invalidation on logout are two of the more frequently underspecified controls — teams often correctly revoke the access token on logout while leaving a long-lived refresh token active, which fails Spec 2.2.1 even though the visible login/logout UX appears correct.
Common Objections We Hear Before Teams Scope a CASA Assessment
We already run web penetration tests — don’t they cover this?
Possibly some of it. A general web pentest and a CASA assessment can overlap heavily on injection and access-control testing, but a pentest report isn’t structured against CASA’s specific Spec IDs, and pentests frequently don’t isolate OAuth flow validation, session-token lifecycle behavior, or configuration controls like DNS/subdomain-takeover exposure with the same granularity CASA’s audit test cases require. The practical question isn’t “do we have security testing,” it’s “can we map our existing evidence line-by-line to each Spec ID,” which is exactly what a scoping review checks before you commit to a full assessment.
We don’t know if our authentication, OAuth, and TLS setup would pass.
This is precisely what assessor-led scoping and a readiness assessment resolve before the formal, submission-grade assessment starts — cheaper to find a gap in a scoping call than mid-assessment.
We need clarity on scope before committing budget.
First-party components, shared backends, and any third-party API touching authentication or user data are candidates for inclusion — but the exact boundary (which services, which environments, which third-party integrations) has to be defined per application. That definition step is a deliverable in itself, not something to assume from a template.
How ValueMentor Approaches CASA Engagements?
ValueMentor is an ADA Authorized Lab for the applicable CASA profile (verify current authorized-lab listing before relying on this for a specific engagement), and structures CASA work around the assessment lifecycle rather than remediation:
- Assessor-led scope definition — first-party target application(s), shared backend/API dependencies, and in-scope third-party sensitive-operation APIs are documented and agreed before testing starts, directly addressing the scope ambiguity most teams flag as their biggest blocker.
- Web and API test coverage mapped to every CASA Spec ID across Authentication, Session Management, Access Control (including OAuth 2.0 flow and redirect/state validation), Communications, Data Validation, and Configuration.
- Evidence-pack review — for AL1 engagements, verification that submitted SAST/DAST artifacts, configuration exports, and compliance statements actually substantiate each test case rather than describing intent.
- Finding validation and certification-submission support — findings are validated against CASA’s acceptance criteria and packaged for the certification workflow; ValueMentor does not issue the final certificate — that determination is made by the Alliance certification body.
Applications integrating multiple third-party authentication or payment APIs tend to under-scope the third-party boundary — teams often assume a vendor’s own security posture “covers” the integration, when CASA specifically requires testing the sensitive-operation-handling configuration *as used by the target application*, not the vendor’s platform in isolation.
CASA does not replace a full secure SDLC program, privacy compliance work, or broader penetration testing outside its control set — and no assessment can guarantee certification outcome, a fixed timeline, or zero findings. What a structured scoping and evidence-review process can do is reduce the number of assessment cycles needed to reach a submission-ready state.
Frequently Asked Questions
What is CASA certification?
CASA (Cloud Application Security Assessment) is the App Defense Alliance’s certification scheme for web applications and web-accessible APIs, built on OWASP ASVS and executed through ADA-authorized labs at either AL1 (verified self-assessment) or AL2 (lab assessment) assurance levels.
How is AL1 different from AL2 in practice?
AL1 requires the developer to generate and submit evidence — including automated scan artifacts — for every audit test case, which an authorized lab then reviews. AL2 requires the lab to directly execute each test case against the live application, with the developer supplying supporting information only where requested.
Does passing a general web penetration test satisfy CASA?
Not automatically. Overlap exists, particularly on injection and access-control testing, but CASA’s audit test cases require specific, ID-mapped evidence — including OAuth flow validation, session-token lifecycle behavior, and configuration controls that a general pentest report typically isn’t structured to demonstrate directly.
Who issues the final CASA certificate?
The Alliance certification body verifies and issues the final certification outcome; an authorized assessment lab validates findings and supports the submission but does not issue the certificate itself.
What’s out of scope for a CASA assessment?
Third-party APIs the target application doesn’t use, non-sensitive third-party operations, and anything outside the defined ASVS-aligned control set — including broader secure SDLC maturity and privacy/regulatory compliance.
Conclusion
CASA isn’t just another security checklist to complete or another certification to display on a website. It reflects a growing shift in how application security is evaluated—from saying an application is secure to proving it with evidence.For many organizations, the assessment itself isn’t the hardest part. The real challenge is understanding what’s in scope, knowing whether existing security testing actually satisfies CASA requirements, and identifying the gaps before they become costly delays.
The teams that approach CASA as a readiness exercise rather than a compliance obligation often gain something far more valuable than certification: a clearer understanding of their application’s security posture and greater confidence in the systems they’ve built. Whether you’re pursuing AL1 or AL2, investing time in preparation today can make the assessment smoother, strengthen your security program, and help you build lasting trust with customers, partners, and stakeholders.
Ready to see where your application stands against the actual Spec IDs above? Request a CASA readiness assessment scoping call with ValueMentor and you’ll receive a preliminary scope breakdown covering which first-party and third-party components would fall in-boundary, which of your existing SAST/DAST/pentest evidence likely maps to specific controls, and what an AL1 versus AL2 path would look like for your architecture.
