10h (edited) • General discussion
CASA SAQ đź”’ The Exact Questions - Full List
Because my extension uses gmail.modify and authenticates through OAuth, Google automatically triggered a CASA review. It’s a thorough process, and for anyone trying to prepare, here are the actual SAQ questions I received.
FYI... I went through TAC Security for the CASA review as that is what google recommeneded. However, thre was one peice of it that my developer José saved me over $1000 becuase of how TAC Security lists the pricing options. I'll document that later and put a link here when its up.
Here are the questions:
1. Verify documentation and justification of all the application's trust boundaries, components, and
significant data flows.
2. Verify the application does not use unsupported, insecure, or deprecated client-side technologies
such as NSAPI plugins, Flash, Shockwave, ActiveX, Silverlight, NACL, or client-side Java applets.
3. Verify that trusted enforcement points, such as access control gateways, servers, and serverless
functions, enforce access controls. Never enforce access controls on the client.
4. Verify that all sensitive data is identified and classified into protection levels.
5. Verify that all protection levels have an associated set of protection requirements, such as encryption
requirements, integrity requirements, retention, privacy and other confidentiality requirements, and that
these are applied in the architecture.
6. Verify that the application employs integrity protections, such as code signing or subresource
integrity. The application must not load or execute code from untrusted sources, such as loading
includes, modules, plugins, code, or libraries from untrusted sources or the Internet.
8. Verify that the application has anti-automation controls to protect against excessive calls such as
mass data exfiltration, business logic requests, file uploads or denial of service attacks.
9. Verify that files obtained from untrusted sources are stored outside the web root, with limited
permissions.
10. Verify that files obtained from untrusted sources are scanned by antivirus scanners to prevent
upload and serving of known malicious content.
11. Verify API URLs do not expose sensitive information, such as the API key, session tokens etc.
12. Verify that authorization decisions are made at both the URI, enforced by programmatic or
declarative security at the controller or router, and at the resource level, enforced by model-based
permissions.
13. Verify that enabled RESTful HTTP methods are a valid choice for the user or action, such as
preventing normal users using DELETE or PUT on protected API or resources.
14. Verify that the application build and deployment processes are performed in a secure and
repeatable way, such as CI / CD automation, automated configuration management, and automated
deployment scripts.
15. Verify that the application, configuration, and all dependencies can be re-deployed using automated
deployment scripts, built from a documented and tested runbook in a reasonable time, or restored from
backups in a timely fashion.16. Verify that authorized administrators can verify the integrity of all security-relevant configurations to
detect tampering.
17. Verify that web or application server and application framework debug modes are disabled in
production to eliminate debug features, developer consoles, and unintended security disclosures.
18. Verify that the supplied Origin header is not used for authentication or access control decisions, as
the Origin header can easily be changed by an attacker.
19. Verify that cookie-based session tokens utilize the 'SameSite' attribute to limit exposure to
cross-site request forgery attacks.
20. Verify that the application protects against LDAP injection vulnerabilities, or that specific security
controls to prevent LDAP injection have been implemented.
21. Verify that the application protects against Local File Inclusion (LFI) or Remote File Inclusion (RFI)
attacks.
22. Verify that regulated private data is stored encrypted while at rest, such as Personally Identifiable
Information (PII), sensitive personal information, or data assessed likely to be subject to EU's GDPR.
23. Verify that all cryptographic operations are constant-time, with no 'short-circuit' operations in
comparisons, calculations, or returns, to avoid leaking information.
0
0 comments
CASA SAQ đź”’ The Exact Questions - Full List
powered by
skool.com/chrome-extension-developers-6389
Build Chrome extensions faster. Fix MV3, API, and automation issues other devs can’t... including undocumented problems/freezes Google won’t explain.
Suggested communities
Powered by