ServicesHow We WorkCase StudiesBlogsAbout UsGet Started
arrow_backBack to Blogs
Engineering BlogsSeptember 10, 2026

Enterprise Web Application Security on Google Cloud: A Practical Guide

G

Gagan Kataria

Defense-in-depth web application security architecture on GCP showing Cloud Armor, load balancer, VPC, and IAM layers

Ask ten engineers what "web application security" means and you'll get ten different answers — HTTPS, a WAF, input validation, rate limiting, secure headers. All of them are right, and all of them are incomplete on their own. That's the actual problem: security isn't one control, it's a set of layers, and most teams have a few of them well-covered and others they've never thought about at all.

This post covers those layers properly — starting from the fundamental concept underneath all of it, then walking through how each layer works on Google Cloud specifically, with enough depth that a technical decision-maker can actually evaluate the tradeoffs, not just recognize the buzzwords.

This is the first post in a new series on cloud security engineering. Before diving in, two earlier posts are worth reading as groundwork: why VPC is the foundation every cloud product is built on covers network isolation, and why service accounts are the right way to authenticate cloud workloads covers identity. Both concepts show up again here, as two of the four layers this post walks through.

Key Takeaways

  • Broken Access Control was found in 100% of applications assessed for the OWASP Top 10:2025, finalized January 2026 — the single most common web application risk today.
  • Defense in depth is commonly modeled as layers of an onion — data at the core, with network security, host security, and application security forming the outer layers — so that a failure in any single layer doesn't expose the whole system.
  • 88% of basic web application attacks use stolen credentials, according to Verizon's 2025 DBIR — attackers are mostly logging in, not breaking in, which is why access control matters more than clever exploits.
  • On Google Cloud, the security stack maps cleanly to four layers: edge (Cloud Armor), transport (load balancer + TLS), network (VPC), and identity (IAM/service accounts) — each one covered in this series.
  • The global average cost of a data breach reached $4.44 million in 2025, and the average breach took 241 days to detect — over eight months of undetected exposure.

The Concept Underneath Everything: Defense in Depth

Before getting into GCP specifics, it's worth being precise about the principle that makes all of this hang together, because it changes how you think about every individual control.

Defense in depth is a concept in which multiple, independent layers of security controls are placed throughout a system, with the intent of providing redundancy in case any single control fails or a vulnerability is exploited. It's sometimes visualized as the layers of an onion — data at the core, with network security, host security, and application security forming the outer layers (Wikipedia, Defense in depth (computing)).

The word that matters most there is independent. A WAF and input validation both stopping the same SQL injection attempt isn't redundant waste — it's the point. Consider a service protected only by API authentication: an attacker compromises credentials via phishing, and all data is exposed, because that was the only defense. Compare that to a system where compromised credentials trigger an unusual-access alert from logging, a subsequent SQL injection attempt is rejected by input validation, and even a successful data exfiltration attempt hits encrypted data the attacker can't read (Archman, Defense in Depth & Secure Defaults). Same initial breach. Wildly different outcome, purely because of how many independent layers had to fail in sequence.

This isn't theoretical. The 2017 Equifax breach stemmed from an unpatched web application framework vulnerability — but the damage was compounded because, once inside, attackers were able to access and exfiltrate vast amounts of sensitive data without being detected (Medium, Defense in Depth in Cybersecurity Architecture). One layer failed (patching). A second layer that should have caught the exfiltration — monitoring, data segmentation, egress controls — either didn't exist or didn't work. That's the actual lesson: not "patch your systems," which everyone already knows, but "assume some layer will fail, and make sure it isn't the only one you have."

Layer 1: The Edge — Stopping Attacks Before They Reach You

The outermost layer is the first opportunity to filter traffic, and it's also the cheapest place to stop an attack, because nothing behind it has to spend any compute cycles processing malicious requests.

On Google Cloud, this layer is Cloud Armor. Cloud Armor functions as the dedicated security component of Google's Global Front End, serving as the primary line of defense protecting applications and APIs from a broad spectrum of web and DDoS attacks — including safeguarding against the OWASP Top 10 and mitigating bot and fraud risk through reCAPTCHA Enterprise integration (Google Cloud Blog, Cloud Armor named Strong Performer in Forrester WAVE, October 2025). Independent validation matters here too: Cloud Armor was named a "Strong Performer" in The Forrester Wave for Web Application Firewall Solutions, Q1 2025 — this isn't just Google's own marketing claim about its product.

Practically, this means every Application Load Balancer we deploy — the same pattern covered in the Cloud Foundations load balancing posts — sits behind a Cloud Armor security policy. The basic configuration includes default protection against volumetric Layer 3 and Layer 4 DDoS attacks, preconfigured WAF rules based on the ModSecurity Core Rule Set, and an edge security policy that filters incoming requests before they ever reach protected backend services (Google Cloud Architecture Center, Use Google Cloud Armor, load balancing, and Cloud CDN to deploy programmable global front ends).

A basic Cloud Armor policy in Terraform looks like this:

resource "google_compute_security_policy" "app_policy" {
  name = "enerasoft-app-edge-policy"

  # Preconfigured WAF rule — blocks common SQLi patterns
  rule {
    action   = "deny(403)"
    priority = 1000
    match {
      expr {
        expression = "evaluatePreconfiguredExpr('sqli-stable')"
      }
    }
    description = "Block SQL injection attempts"
  }

  # Preconfigured WAF rule — blocks common XSS patterns
  rule {
    action   = "deny(403)"
    priority = 1001
    match {
      expr {
        expression = "evaluatePreconfiguredExpr('xss-stable')"
      }
    }
    description = "Block XSS attempts"
  }

  # Default rule — allow everything else
  rule {
    action   = "allow"
    priority = 2147483647
    match {
      versioned_expr = "SRC_IPS_V1"
      config { src_ip_ranges = ["*"] }
    }
    description = "Default allow"
  }
}

Cloud Armor's WAF inspection is continuing to expand — request body inspection grew from 8 KB to 64 KB, alongside JA4 network fingerprinting for more precise client identification, both rolling out through 2025 into 2026. This is worth knowing as a decision-maker: edge WAF capability isn't static, and a security architecture reviewed a year ago may not reflect what's currently possible at this layer.

Layer 2: Transport — TLS Termination and Where It Belongs

The next layer is about how traffic actually gets encrypted between the user and your infrastructure, and where that encryption is terminated matters more than most teams realize.

The standard, correct pattern is terminating TLS at the load balancer rather than at each individual backend instance. This does two things: it centralizes certificate management to one place instead of one per server, and it removes the CPU overhead of TLS handshakes from application servers entirely, freeing that compute for actual application logic.

This connects directly to the load balancer architecture covered later in this series — your Application Load Balancer is where certificates live, where HTTPS is enforced, and where traffic gets decrypted before being passed to backends over Google's private network rather than the public internet.

Layer 3: Network — VPC Segmentation

By the time traffic reaches this layer, it's already been filtered by Cloud Armor and decrypted at the load balancer. The network layer's job is making sure that even if something gets past the first two layers, it can't freely roam your infrastructure.

This is the VPC architecture covered in depth in our earlier post on VPC: public subnets hold only what needs to be internet-facing (the load balancer itself), while application servers and databases live in private subnets with no public IP addresses at all. An attacker who somehow bypasses the WAF still has to contend with the fact that your database was never reachable from the internet in the first place.

Worth noting: This is where the "independent layers" principle from earlier really pays off. Cloud Armor failing to catch a novel attack pattern doesn't matter as much if that attack still can't reach a database with no public IP. The layers aren't just theoretical redundancy — they're doing genuinely different jobs.

For APIs specifically, this same segmentation applies: internal APIs that only need to be called by other services within your architecture should sit behind an Internal Application Load Balancer, never exposed externally at all — a distinction covered in the Cloud Foundations post on choosing a GCP load balancer, which walks through internal versus external deployment modes.

Layer 4: Identity — Access Control and Service Accounts

This is the layer that the current OWASP data says matters most, and it's also the layer most teams under-invest in relative to its actual risk.

Broken Access Control was found in 100% of applications assessed for the OWASP Top 10:2025 — worth sitting with, because it means this isn't a rare edge case affecting unlucky teams. It's close to universal. Broken Access Control, ranked as the #1 security risk in the OWASP Top 10, underscores the severe consequences of improper authorization — without robust authentication and precise access controls, attackers can exploit vulnerabilities to escalate privileges or access sensitive data, rendering other security measures ineffective (Medium, Defense in Depth: A Layered Approach to Web Application Security).

That last clause matters: broken access control can render other security measures ineffective. A perfectly configured WAF and a flawlessly segmented VPC don't help if your application logic lets User A read User B's data by changing a number in the URL.

Two specific practices address this on GCP:

Enforce authorization at the data layer, on every request. Not just hiding a UI element — checking, server-side, on every single request to a resource, whether the requesting user is actually allowed to access that specific resource. This has to happen regardless of how the request got there.

Use service accounts, not personal credentials, for every service-to-service call. This is the subject of the service accounts post earlier in this series — every backend service, background worker, and API integration should authenticate with its own named, scoped service account. This matters for access control specifically because a service account scoped to exactly what it needs limits what an attacker can do even if that specific credential is compromised.

Extending This to Mobile, APIs, and Background Pipelines

The four layers above apply to any web application, but they need small adjustments depending on the surface.

Mobile clients talk to your backend the same way a browser does — over HTTPS, through the same load balancer, behind the same Cloud Armor policy. The meaningful difference is that mobile apps run on devices you don't control, which means tokens and API keys embedded in a mobile client should be treated as eventually discoverable. Short-lived tokens with refresh flows, rather than long-lived embedded credentials, are the standard mitigation.

APIs benefit from the exact same four layers, with one addition: rate limiting, typically configured at the Cloud Armor layer using rate-based rules, prevents both abuse and a specific category of access-control bypass where an attacker brute-forces their way past authentication through sheer volume rather than a clever exploit.

Background processes and data pipelines are the surface most commonly left out of security reviews entirely, precisely because they have no user-facing interface to test. The same identity-layer principle applies here directly: a Cloud Function processing incoming data or a Pub/Sub worker moving records between systems needs its own scoped service account, not a shared one borrowed from somewhere else in the architecture. Data in transit between pipeline stages should be encrypted the same way user-facing traffic is, and audit logging — covered as a baseline practice in the service accounts post — matters just as much for automated processes as it does for human-facing ones, since audit logs are frequently what actually reveals the extent of an attack after the fact, even when earlier layers failed to stop it (Archman, Defense in Depth & Secure Defaults).

Frequently Asked Questions

What is defense in depth, in plain terms?

Defense-in-depth security architecture is based on controls designed to protect the physical, technical, and administrative aspects of a system — the principle being that even if attackers get past one control, such as a firewall, additional controls like encryption mean the data they reach is still protected (Imperva, What is Defense in Depth). It's the practice of not relying on any single security control to be perfect.

Do I need a WAF if my application code is already secure?

Yes — because "secure code" isn't a permanent state, it's a moving target as new vulnerability classes emerge, and a WAF catches known attack patterns before they reach your application regardless of whether your code has been patched for that specific issue yet. Defense in depth means that if one layer fails or contains a vulnerability, additional layers can still prevent successful attacks — a WAF and secure code aren't redundant, they're covering different failure modes.

What's the single highest-priority layer if I can only fix one thing?

Based on current data, access control. It's now present in 100% of tested applications, and it can render other security measures ineffective when broken, since an attacker who can already reach data they shouldn't doesn't need to defeat your other defenses at all.

How does this apply to background jobs and pipelines that have no user interface?

The same four layers apply, adjusted for the fact that there's no browser involved. Network segmentation still matters (pipeline workers shouldn't have public IPs), identity still matters (each worker needs its own scoped service account), and audit logging still matters — arguably more, since there's no user to notice something looks wrong.

Where This Leaves You

None of these four layers are exotic. Edge filtering, TLS termination, network segmentation, and identity-based access control are all well-understood, well-documented patterns. The actual differentiator between teams with strong security posture and teams with gaps isn't knowledge of these concepts — it's whether all four layers were actually implemented, deliberately, rather than assumed to be someone else's responsibility or handled implicitly by the cloud platform.

This post builds directly on two earlier posts — VPC for the network layer and service accounts for identity — and on the load balancer architecture from our Cloud Foundations series for the transport layer. This is where all of that groundwork comes together into one complete picture. If you're architecting a new application or reviewing an existing one and want a second pair of eyes on how these layers fit together, we'd be glad to talk it through.

Written by Gagan Kataria, Founder & CEO at Enerasoft Technologies LLP — an AI-powered software and cloud engineering company based in Hisar, Haryana, India. This is Part 1 of the Cloud Security series.

Sources

Enterprise SecurityOWASPCloud ArmorGCPWeb Application SecurityDefense in Depth