How to Complete the Google CASA AL1 SAQ: A Step-by-Step Guide

What is the Google CASA AL1 SAQ?

The CASA AL1 SAQ is the self-assessment questionnaire developers complete for CASA Assurance Level 1, which the CASA specification defines as a Verified Self Assessment. For each applicable security requirement you state how your application satisfies it and provide supporting evidence, and an approved assessment lab reviews that information. It is not a form where you tick “Yes” against every control.

A better way to think about it: for every applicable requirement, understand what it asks, determine whether your application satisfies it, and be able to support your answer.

What is Google CASA?

CASA stands for Cloud Application Security Assessment — a consistent way of assessing applications that integrate with cloud platforms and may access sensitive user data. It is based on the OWASP Application Security Verification Standard (ASVS); the App Defense Alliance states that CASA requirements are derived from ASVS rather than a separate proprietary standard.

Google uses CASA as part of its application-security assurance process. If Google requires your application to complete CASA, the notification should state the assessment level and deadline. You then work with an authorized assessor, who provides a Letter of Validation (LoV) after successful completion.

CASA AL1 vs AL2

CASA currently has two assurance levels. The requirements themselves are not optional at AL1: applications must satisfy all CASA requirements applicable to them, and the level changes how those requirements are assessed and validated.

Before you start

Don't start by answering questions. Spend 15–30 minutes documenting how your application works, and get input from at least one developer or DevOps engineer. Don't guess.

Understand your CASA scope first

The specification says a target web application may consist of multiple first-party components that operate together, and shared first-party backend components or APIs used by the application can also fall in scope. Third-party services matter too: if an external identity provider performs authentication, that integration can be relevant to the authentication, session-management and access-control requirements.

A simple architecture might be Browser → React frontend → Node.js API → PostgreSQL, plus Google OAuth into the application and perhaps the application calling the Gmail API. The assessment should reflect the complete application flow, not just the public homepage.

How to answer CASA questions: Yes, No or N/A

For most requirements you are establishing one of three conditions.

• Yes — the requirement applies and your application currently implements the control. Not because you plan to, because your developer thinks it probably does, because your framework may do it by default, or because it sounds like the right answer. Verify it.
• No — the requirement applies but isn't satisfied. For example, if your internet-facing admin console uses only a password, don't mark MFA as Yes because it is planned. Record the current state and remediate; CASA requires applicable requirements to be satisfied before verification.
• Not Applicable — the requirement genuinely can't apply to your architecture, and you can explain why. For example, “authentication is handled exclusively through Google OAuth” may make some password-specific controls irrelevant, depending on the exact requirement. Never use N/A because you don't understand a question.

The formula: Requirement → Implementation → Evidence

For every applicable requirement, answer three questions: What is CASA asking, in plain English? How does your application actually satisfy it? How could you demonstrate that?

For example, for “session cookies must be protected”: the implementation is an HTTPS-only session cookie with the Secure and HttpOnly attributes, and the evidence could be a browser developer-tools screenshot, the framework configuration, or the Set-Cookie response header. That is far stronger than “Yes, cookies are secure.”

Authentication and verification codes

CASA looks at how users prove their identity: password security, default accounts and out-of-band verification. If you use passwords, be ready to explain how brute-force attacks are mitigated, how passwords are stored, whether generated passwords or activation codes expire, and whether default credentials exist. “Passwords are encrypted” is ambiguous; “passwords are stored using a password-hashing mechanism, never in plaintext, and authentication endpoints are rate limited” is an answer.

If you use Google OAuth instead of passwords, don't automatically answer every authentication question N/A. Check whether you also maintain application passwords, whether administrators use another login, whether account recovery exists, and whether the application generates temporary codes.

If you send verification codes by email, SMS or another channel, the specification expects them to expire in a reasonable period, be single-use, be securely random and resist brute force. Describe your real implementation — for example, tokens from a cryptographically secure generator that expire after a stated period, become invalid on use, and have rate-limited verification attempts. Don't quote numbers that aren't true of your system.

Session management, cookies and logout

Once a user logs in you normally create a session cookie, access token, refresh token or JWT. CASA asks whether these are handled securely.

• Keep authentication material out of URLs. Passwords and session tokens in query strings can end up in browser history and server logs — prefer cookies or authorization headers.
• Check cookie attributes. Cookie-based session tokens should use Secure (no transmission over plain HTTP) and HttpOnly (no access from client-side JavaScript). Browser developer tools will show both.
• Test logout properly. Log in, copy the session token, log out, then try to reuse the old token. If it still works, the session isn't really invalidated. Also consider session expiry, password changes, refresh tokens and long-lived stateless tokens.
• Don't confuse server-to-server API credentials with user session tokens — they are different use cases, and CASA expects session tokens rather than long-lived static API secrets for user sessions.
• Consider sensitive account changes. If someone obtains an unlocked browser session, what can they do — change a password, change recovery details, start a sensitive data operation? Document the protections you actually use.

Access control: authorization, IDOR and least privilege

Authentication answers “who are you?”; authorization answers “what are you allowed to do?”. CASA expects access-control decisions to be enforced in a trusted service layer, not solely in the frontend.

A classic failure: the UI only shows User A their own records, but requesting /api/customer/123 and then changing it to /api/customer/124 returns another customer's record. That is an Insecure Direct Object Reference (IDOR), and CASA includes protection against it.

For least privilege, ask whether each user has only the access their role needs. A normal user shouldn't reach administrator APIs, system settings, all-customer data or other users' private records. A good answer: “The application implements role-based access control in the backend API. Authorization is checked on each protected request and is not determined solely by client-side functionality.”

If your application uses browser sessions, also verify CSRF protection — anti-CSRF tokens, SameSite cookies, origin validation or framework middleware. Don't assume your framework handles it; verify.

Google OAuth and administrative MFA

Many applications reach CASA because they use Google APIs, so the OAuth requirements deserve care. CASA expects secure flows — Authorization Code Flow, or Authorization Code Flow with PKCE — rather than deprecated flows such as Implicit or Resource Owner Password Credentials. It also expects proper validation of parameters such as redirect_uri and state, which defend against open redirects and cross-site request forgery.

A typical answer, if it matches your application: “The application uses Google's OAuth 2.0 Authorization Code Flow. Redirect URIs are explicitly registered and restricted, and the state parameter is generated and validated for authorization requests.”

If you have an internet-accessible administration portal such as admin.example.com, the specification requires appropriate multi-factor authentication for it. Don't confuse your application admin console with your AWS, Azure or GCP management console.

Communications, input validation and file uploads

For communications security, check production website and API HTTPS, backend service traffic where applicable, certificates, weak TLS protocols or ciphers, and HTTP-to-HTTPS redirection. “We use SSL” isn't an explanation; “all public endpoints are available only over HTTPS, HTTP is redirected, and TLS terminates at the production load balancer” is.

Your application receives hostile input everywhere — forms, APIs, URL parameters, headers, uploaded files, JSON. Client-side validation helps usability but shouldn't be your primary security control, so consider both frontend and backend when answering.

If users can upload anything — profile pictures, invoices, PDFs, CSV imports, attachments — don't mark file-upload requirements N/A. Ask which types are allowed, whether MIME type and extension are validated, whether files can execute, where they're stored, whether filenames are controlled, whether malware scanning runs, and whether users can retrieve each other's files.

Configuration, logging, browser storage and secrets

These areas are where cloud applications most often slip.

• Dependencies: CASA expects components to be kept up to date. Tools like Dependabot, npm audit, Snyk, Renovate or GitHub/GitLab scanning help, but a tool alone isn't enough — you need a process for acting on findings.
• Debug mode: stack traces, internal paths, environment details and debugging interfaces must be off in production. Check production, not your local configuration.
• Logging: CASA addresses keeping credentials and payment details out of logs. Search logs for passwords, authorization headers, session tokens, API keys, OAuth secrets and card data — especially if you debug-log complete HTTP requests.
• Browser storage: check Local Storage, Session Storage, IndexedDB and cookies in developer tools, including whether sensitive data remains after logout.
• Server-side secrets: OAuth client secrets, database passwords, API keys, JWT signing keys and third-party tokens shouldn't live in source code, public repositories, frontend JavaScript, container images or committed configuration. Use a secrets manager (AWS Secrets Manager, Azure Key Vault, Google Secret Manager, HashiCorp Vault) or appropriately protected environment variables.

A worked example: AcmeCRM

Consider a fictional SaaS app, AcmeCRM: hosted in AWS, React frontend, Node.js APIs, PostgreSQL, Google OAuth with Gmail access, secrets in AWS Secrets Manager. Here is how weak and strong answers differ.

How much evidence to provide — and what to remove

Provide enough to demonstrate the control without exposing unnecessary sensitive information. The specification recognizes code snippets — screenshots or text excerpts — without requiring your complete source code. Useful evidence includes screenshots, configuration excerpts, cloud configuration, authentication settings, HTTP headers, architecture diagrams, scan output, dependency-management results and relevant policies.

Before uploading anything, remove or mask passwords, API keys, OAuth client secrets, private keys, session and access tokens, and database credentials. Good: GOOGLE_CLIENT_SECRET = ********. Bad: the real value. Your assessment shouldn't create a new security incident.

Common CASA AL1 SAQ mistakes

1. Marking everything Yes. A Yes means the control actually exists.
2. Using N/A whenever a question is difficult. N/A means the requirement doesn't apply, not “I don't know.”
3. Describing planned controls. “MFA will be implemented next week” is a remediation plan, not a current implementation — implement and verify first.
4. Giving one-word answers. AL1 depends on your statements and evidence; explain how the requirement is met.
5. Having one developer complete it alone. Code, cloud, OAuth, databases, IAM and logging often have different owners.
6. Confusing authentication with authorization. Being logged in doesn't mean being allowed to access every resource.
7. Looking only at the frontend. A React button disappearing for unauthorized users isn't access control — check the backend API.
8. Assuming your framework makes you compliant. Django, Laravel, Spring, Rails or Next.js provide strong features, but they must be correctly configured and used.
9. Forgetting your APIs. Shared backend APIs used by the assessed application can be in scope.
10. Ignoring what your scanner finds. If your answers say there are no weaknesses but a scan reports exposed cookies, outdated libraries or injection flaws, resolve the discrepancy before submitting.

What if the honest answer is No?

A No isn't something to hide; it identifies a control that needs attention. Follow the loop: identify, understand, remediate, verify, update, submit. For example, if the admin interface doesn't require MFA, enable MFA for administrator accounts, test the admin login, then update your answer to Yes.

CASA AL1 pre-submission checklist

Before sending your questionnaire and evidence to the assessor, confirm each of the following.

• You understand exactly which application is being assessed, and relevant web applications and APIs are in scope.
• Every CASA requirement has been reviewed.
• Yes answers describe controls that are implemented today; N/A answers have a defensible technical explanation; No answers are identified for remediation.
• OAuth configuration has been reviewed, and authentication and authorization have been considered separately.
• Session behaviour has been tested, and administrative interfaces use appropriate MFA.
• Production debug settings are checked, dependencies are reviewed, secrets are stored securely and sensitive data isn't written to logs.
• Evidence is available and contains no passwords, tokens or private keys.
• Responses match actual application behaviour, and identified weaknesses have been remediated and retested.

What happens after you complete the SAQ?

The self-assessment is one part of CASA AL1. The normal flow:

1. Receive the CASA requirement from Google or another CASA Framework User.
2. Confirm the required assurance level — the Framework User sets it, not the developer.
3. Select an authorized assessor and provide them with your notification.
4. Complete your self-assessment and prepare statements and evidence.
5. Resolve security gaps for applicable requirements that aren't satisfied.
6. Submit for assessment; the authorized lab reviews the AL1 self-assessment and evidence.
7. Complete any requested clarification or remediation.
8. Receive your Letter of Validation, which the assessor provides to you and the Framework User after successful completion.

Timeline, penetration testing and scanners

How long AL1 takes depends far more on your application's readiness than on the questionnaire. An application with secure OAuth, good session management, MFA, appropriate access controls, secure secrets and maintained dependencies may move quickly; one needing remediation will take longer.

Don't automatically equate AL1 with a full manual penetration test — AL1 is a Verified Self Assessment, whereas AL2 involves direct assessment by the lab. Security testing can still help validate your statements, and if you need broader manual testing you may consider AL2 or a separate application penetration test.

Tools such as OWASP ZAP and Burp Suite help find common vulnerabilities, but a scanner doesn't answer every requirement. Authentication architecture, authorization logic, OAuth implementation, secret management, administrative MFA, dependency management and session design may need configuration evidence, code review or technical explanation. Treat scanning as one source of evidence, not the whole assessment.

Does completing the SAQ mean I've passed?

No. Completing the questionnaire means you've prepared your self-assessment. Successful CASA verification still depends on the applicable requirements being satisfied and the assessment process being completed through an appropriate assessor. Nor does CASA guarantee your application is secure — it is a structured assessment based on defined requirements, not a guarantee against future vulnerabilities or attacks.

Frequently asked questions

What is a CASA SAQ?

The CASA self-assessment is the developer's assessment of how an application satisfies applicable CASA security requirements. Under the current AL1 model, the developer supplies statements and evidence that an approved lab reviews.

Who decides whether I need CASA AL1 or AL2?

The organization requiring CASA, known as the Framework User, determines the required assurance level based on its risk assessment.

Can I choose CASA AL1 instead of AL2?

Not if your CASA notification requires AL2. The required assurance level is set by the Framework User, not the developer.

Do I need to satisfy every CASA requirement?

You need to satisfy every requirement applicable to your application. Some requirements may legitimately be non-applicable based on your architecture.

Can I answer N/A to a CASA question?

Yes, where the requirement genuinely does not apply. Be prepared to explain the technical reason.

What happens if my application fails a requirement?

Remediate the issue, verify the fix and provide updated information or evidence to the assessor as required.

What is the CASA Letter of Validation?

After successful completion of a Framework User-initiated CASA assessment, the authorized assessor provides the validation outcome to the developer and the Framework User.

Does CASA need to be renewed?

The App Defense Alliance states that CASA applications require annual revalidation.