How Numero Prepared for Google CASA AL1

Numero is built around a narrow promise: turn authorized financial messages into useful structured facts without becoming a permanent email archive. Customers should not have to accept that promise solely because it appears on a marketing page. Security controls need to be inspectable, testable, and tied to the product that is actually deployed.

CASA gives that work a consistent frame. Its requirements examine the areas where an application can lose control of sensitive data: weak authentication, long-lived or replayable sessions, missing authorization boundaries, unsafe transport, injection, vulnerable dependencies, debug exposure, and careless logging. For Numero, the value was not a badge. It was the discipline of proving each claim against the same defined scope.

The assessment scope was the production website and API at hellonumero.com and api.hellonumero.com. Mobile-specific endpoints and terminology were deliberately excluded because the mobile application had not been disclosed in the assessment portal. That boundary matters: evidence is misleading when it mixes controls from a product the assessor was not asked to review.

We also tied evidence to concrete source versions and deployed behavior. Code excerpts were pinned to a commit, scan configurations recorded their own hashes, and live transcripts identified the target and date. This made it possible to distinguish a control that existed in source from one that was operating in production.

The first readiness review did not produce a ceremonial pass. It found places where production should fail closed and where privacy protections needed stronger enforcement. The remediation report tracked each finding to a disposition, implementation, and verification step.

Production configuration now rejects weak JWT secrets, known development encryption keys, non-TLS PostgreSQL settings, and debug logging. OAuth transaction cookies use a dedicated encryption key. Logout writes token fingerprints to a server-side revocation store so access and refresh tokens can be rejected immediately. Password login and public support requests are rate-limited. Account deletion is connected to the product, and temporary extraction-comparison data expires after 90 days.

Logging was tightened so restricted Gmail content, AI context, recipients, model output, and extracted fields do not enter application logs. Security headers were rebuilt around a per-request Content Security Policy nonce, strict framing restrictions, HSTS, MIME protections, and narrow third-party origins. These changes were useful independently of the assessment because they reduced the consequences of configuration mistakes and future regressions.

Several controls were implemented correctly but still came back because the evidence was too narrow. A database column did not prove how passwords were hashed. Naming a redirect-validation helper did not show its implementation. A source search over the API did not cover the browser application. An unauthenticated baseline scan did not prove what happened inside a real session.

We treated those responses as evidence defects, not paperwork friction. Complete functions replaced path-only citations. Searches were widened to the declared application scope. Missing regression tests were added for algorithm confusion, cryptographic failure behavior, directory browsing, storage clearing, and provider-specific OAuth paths. Authenticated scans and black-box lifecycle scripts replaced assumptions about runtime behavior.

That distinction became one of the most valuable outcomes of the process: correct code and reviewable evidence are separate deliverables. A control is easier to trust when another person can see what enforces it, reproduce the relevant test, and understand the result without relying on the author's interpretation.

By August 30, the evidence pack covered authentication, session management, access control, communications, data validation, and configuration. Authenticated OWASP ZAP runs and companion scripts had been executed for the rows requiring live verification, and per-item image sets were prepared for portal submission or resubmission.

Numero subsequently completed the CASA AL1 assessment, and the assessor submitted the Letter of Validation to Google in 2026.

Some evidence necessarily lives outside source control. Provider-side contractual terms, managed database encryption evidence, selected Cloudflare dashboard settings, and proof of production secret rotation require operator-supplied artifacts. The remediation report calls those dependencies out rather than treating code as proof of a provider control.

Security assessment is also a point-in-time activity. New dependency advisories appeared only thirteen days after an earlier scan, which led to another toolchain update and documented residuals. Numero therefore treats scanning, patching, and evidence refresh as continuing work, not something completed forever by one review cycle.