Security becomes non-negotiable the moment an application touches a user’s Google account.

When an app requests access to Gmail, YouTube, or Google Drive, it is no longer just a product feature—it is a responsibility. That responsibility is exactly why Google requires applications using Sensitive APIs to undergo CASA (Cloud Application Security Assessment).

This post documents our CASA journey openly—how we went from an initial score of 8.5, improved to 8.8, and ultimately reached 9.1—and what we changed along the way to meet Google’s security expectations, without exposing sensitive implementation details.

What is CASA and Why Google Requires It

CASA (Cloud Application Security Assessment) is Google’s security review program for applications that use Sensitive or Restricted Google APIs.

The goal of CASA is simple but strict:

• Ensure user data is accessed only with explicit consent

• Reduce risk from common web vulnerabilities

• Validate that modern security best practices are followed

• Prevent accidental data exposure due to weak defaults or misconfigurations

Google requires CASA because APIs like Gmail, YouTube, and Drive allow actions that directly affect a user’s data, identity, and digital presence. Any weakness in an application using these APIs can have real-world consequences.

CASA is not about achieving “perfect security.”

It’s about proving that security is treated as a first-class responsibility, not an afterthought.

Google APIs We Use (High-Level Overview)

Our application integrates with the following Google APIs:

• Gmail API – used to send emails on behalf of users, strictly under explicit OAuth permission

• YouTube API – used to manage user-authorized channel actions

• Google Drive API – used to access user-selected files only, never broad or unrestricted Drive access

All access is permission-based, consent-driven, and scoped to what users explicitly approve.

We intentionally do not disclose OAuth scopes, token handling logic, or encryption strategies publicly. CASA validates those internally, and publishing them would weaken—not strengthen—security.

The CASA Assessment Journey

Phase 1: Initial CASA Scan (Score: 8.5)

Our first CASA scan gave us a solid baseline but also highlighted areas where security could be strengthened.

The findings were primarily Low and Informational in severity—no critical or high-risk vulnerabilities—but CASA does not treat low-risk issues as ignorable.

Image 1.png

What the 8.5 Score Told Us

This score meant the application was functional and generally secure—but not fully hardened.

The findings mostly fell into categories such as:

• Missing or incomplete security headers

• Information disclosure through response metadata

• Cache behavior that needed stricter controls

• Cross-domain and integrity-related warnings

• Default configurations that were safe, but not defensive enough

• For security reasons, only a partial summary of the scan results is shown here. Detailed findings and system-specific information are intentionally not published.

Even though these issues were not severe on their own, collectively they represent exactly the kind of surface attackers look for. CASA exists to eliminate those surfaces.

Phase 2: First Remediation & Rescan (Score: 8.8)

After reviewing the first report, we moved into remediation with a clear goal:
reduce exposure, harden defaults, and remove unnecessary signals.

We implemented targeted improvements across the platform and ran a second scan.

Image 2.png

What We Fixed in This Phase

1. Platform-Level Security Headers
We enforced modern security headers across the application to protect against:

• Clickjacking

• MIME sniffing

• Injection-style attacks

• Downgrade attacks (HTTP → HTTPS)

These protections were applied consistently at the platform level to avoid per-route gaps.

Image 3.png

The snippet above is intentionally simplified and illustrative. Our full production configuration includes additional protections and is not published publicly to avoid exposing security posture details.

2. Reduced Server Fingerprinting
We removed or neutralized response headers that unnecessarily revealed server or framework information. This doesn’t change behavior—but it reduces what attackers learn for free.

3. Hidden File & Path Protection
Explicit handling was added to prevent exposure of hidden files, system artifacts, and internal paths that scanners commonly probe.

4. Cache Behavior Hardening
Sensitive responses were protected against being cached or served from shared storage layers.

** For security reasons, only a partial summary of the scan results is shown here. Detailed findings and system-specific information are intentionally not published.*

The result: an improved score of 8.8 and a cleaner security posture.

Phase 3: Deep Hardening & Final Scan (Score: 9.1)

The final phase focused on what users never see—but attackers always test.

This is where security maturity is built.

Image 4.png

What Changed in the Final Phase

1. OAuth Flow Hardening
Because we use Gmail, YouTube, and Drive, OAuth is a core security boundary.

We strengthened:

• Consent-based access enforcement

• Least-privilege permission handling

• Token lifecycle safety and misuse prevention

While we don’t publish OAuth internals, CASA validated that our implementation aligns with Google’s security expectations for sensitive APIs.

2. Encryption & Sensitive Data Handling
We improved how sensitive data is treated across the application:

• Stronger encryption practices where applicable

• Better isolation of secrets and credentials

• Ensuring sensitive values never appear in logs, headers, or responses

3. Content Security Policy & Browser Controls
We tightened CSP and browser permissions to reduce risk from:

• Cross-domain script inclusion

• Unsafe inline execution patterns

• Unnecessary browser feature access (camera, mic, sensors, etc.)

4. Defense-in-Depth Improvements
Even when a control fails, additional safeguards exist. That layered approach is what moved the score to 9.1.

• For security reasons, only a partial summary of the scan results is shown here. Detailed findings and system-specific information are intentionally not published.
  
  It’s worth noting that while automated CASA scans may continue to flag certain low-severity or informational items as “open,” the final assessment includes a manual review by Google’s security team. After human validation and contextual evaluation, our application was fully approved and issued a Letter of Validation (LOV), formally confirming compliance with CASA requirements.

What We Fixed (Without Exposing Internals)

To keep this transparent but safe, here’s a category-level summary of what was addressed:

• Clickjacking protection and framing policies

• Content execution and injection hardening

• Server metadata and information exposure reduction

• Cache isolation for sensitive data

• Protection against hidden and system file exposure

• OAuth consent enforcement and encryption improvements

We intentionally do not publish vulnerability URLs, endpoints, scopes, or configuration secrets.

What We’re Not Publishing—and Why

Security transparency does not mean publishing a blueprint for attackers.

We do not share:

• Full vulnerability reports

• OAuth scopes or token flows

• Encryption and key-management strategies

• Full production configurations

• Internal infrastructure identifiers

CASA validates these internally. Public disclosure of such details would weaken security, not strengthen it.

Why This Matters

CASA is not a checkbox.
It’s a signal—to users and partners—that security is taken seriously.

Passing CASA means:

• Users can trust us with sensitive Google access

• Permissions are intentional and controlled

• Weak defaults are actively eliminated

• Security evolves alongside the product

Final Thoughts

This journey reinforced a simple truth:

Good products earn trust. Secure products keep it.

By completing CASA and continuously improving our security posture, we’re not just meeting Google’s requirements—we’re honoring the responsibility that comes with accessing user data.

This post exists to be transparent about that responsibility, without compromising the security we worked hard to build.