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

Securing APIs on Google Cloud: The OWASP API Top 10 in Practice

G

Gagan Kataria

OWASP API Security Top 10 risks mapped to Google Cloud API Gateway and Apigee defenses

Part 1 of this series covered the four layers of defense-in-depth and mentioned APIs almost in passing — the same layers apply, plus rate limiting. That was true, but it undersold how different API security actually is in practice. Web applications and APIs get attacked differently, and OWASP maintains an entirely separate Top 10 list for APIs because the failure patterns don't overlap as much as people assume.

This post goes deep on that separate list, what it means concretely on Google Cloud, and where API Gateway and Apigee fit into an architecture that's already got Cloud Armor, a VPC, and scoped service accounts in place from the earlier posts in this series.

Key Takeaways

  • Broken Object Level Authorization alone accounts for roughly 40% of all API attacks, and has held the #1 spot on the OWASP API Security Top 10 for two editions in a row.
  • There is no separate 2025 or 2026 edition of the OWASP API Security Top 10 — the 2023 release remains the current, authoritative version.
  • Authorization failures dominate the list: API1, API3, and API5 are all variations of the same root problem — an API checking that a caller is authenticated, but not checking what that specific caller is allowed to touch.
  • The Dell API breach in 2024 exposed 49 million customer records after attackers manipulated fake partner accounts to exploit exactly this gap — a textbook Broken Object Level Authorization failure.
  • On GCP, API Gateway handles authentication and rate limiting for straightforward serverless backends; Apigee adds the developer portal, monetization, and advanced threat protection layer once you're managing an API as a product, not just an endpoint.

Why APIs Get Their Own OWASP List

It's a fair question: web apps have the OWASP Top 10, APIs have their own separate OWASP API Security Top 10 — why not one list?

APIs are how modern software talks to itself, and they've become one of the more attacked surfaces in many applications. One pattern jumps out immediately: authorization, the question of who is allowed to do what, dominates the list — API1, API3, and API5 are all authorization failures (TechJack Solutions, OWASP API Security Top 10 (2023): The Risks Explained). A traditional web app has a browser rendering a UI that constrains what a user can click. An API has no such constraint — every endpoint is directly callable by anyone who can construct the right request, which means the authorization check has to happen entirely on the server, every single time, with nothing in the client to fall back on.

That structural difference is why the list looks the way it does, and why it's worth treating as its own subject rather than an appendix to general web security.

The List, and the Pattern Underneath It

The current OWASP API Security Top 10, last revised in 2023, runs from Broken Object Level Authorization through Unsafe Consumption of APIs (Scribd, OWASP Top 10 API Security Risks – 2023). Here's the full list, with the authorization-heavy pattern visible once you look for it:

OWASP API Security Top 10 (2023 — current edition)API1 — Broken Object Level Authorization~40% of attacksAPI2 — Broken AuthenticationAPI3 — Broken Object Property Level AuthorizationAPI4 — Unrestricted Resource ConsumptionAPI5 — Broken Function Level AuthorizationAPI6 — Unrestricted Access to Sensitive Business FlowsAPI7 — Server Side Request Forgery (SSRF)API8 — Security MisconfigurationAPI9 — Improper Inventory ManagementAPI10 — Unsafe Consumption of APIsRed = authorization failure (API1, API3, API5) — the dominant pattern on this list
Source: OWASP API Security Top 10, 2023 edition (current as of 2026)

The 2023 revision consolidated Excessive Data Exposure and Mass Assignment from the 2019 list into API3 (Broken Object Property Level Authorization), updated API4 from "Lack of Resources & Rate Limiting" to "Unrestricted Resource Consumption" to stress the root cause rather than the symptom, and added three new risks — Unrestricted Access to Sensitive Business Flows, SSRF, and Unsafe API Consumption — reflecting how automation abuse and third-party integrations have changed the attack surface (Wiz, OWASP API Security Top 10 Risks and How to Mitigate Them).

API1: Broken Object Level Authorization — The One to Fix First

If you only have time to properly defend against one item on this list, this is it.

Object level authorization is an access control mechanism, usually implemented at the code level, that validates a user can only access the objects they should have permission to access. Every API endpoint that receives an object ID and performs an action on that object should implement an authorization check validating that the logged-in user actually has permission to perform that action on that specific object (OWASP, API1:2023 Broken Object Level Authorization).

The exploit pattern is almost embarrassingly simple once you see it: attackers exploit insufficient access controls by modifying API requests — changing an ID in a URL or payload — to access or manipulate data belonging to someone else (Medium, OWASP API Security Top 10). A request like GET /api/invoices/4471 returning your invoice is fine. The vulnerability is when GET /api/invoices/4472 — someone else's invoice — also returns data, because the endpoint checked that a valid user was logged in, but never checked whether this user was allowed to see that specific invoice.

This isn't a hypothetical. In 2024, attackers exploited exactly this gap in Dell's partner portal API, accessing 49 million customer records by manipulating fake accounts — the absence of robust object-level authorization allowed unauthorized access to sensitive data at scale (Medium, OWASP API Security Top 10, citing the Dell API breach).

The fix, concretely: every endpoint that takes a resource ID needs a server-side check — "does the authenticated user own or have explicit permission for this specific object?" — before the query even runs, not after. This check belongs in application code, not at the network or gateway layer, because only your application actually knows the ownership relationship between users and their data.

API2, API3, API5: The Rest of the Authorization Problem

The other two authorization-related entries extend the same principle to different scopes.

API2 — Broken Authentication covers the layer before authorization even applies: weak authentication mechanisms that let attackers impersonate users, often through insecure token handling, weak passwords, or a lack of multi-factor authentication. On GCP, this is where OAuth 2.0 and short-lived, properly-scoped tokens matter — Apigee's recommended security model layers OAuth 2.0 and OpenID Connect at the API level, with TLS and API keys at the application level (Google Cloud Architecture Center, Best practices for securing your applications and APIs using Apigee), rather than long-lived static API keys as the sole authentication mechanism.

API3 — Broken Object Property Level Authorization represents a critical gap in how APIs control access to individual data fields — APIs routinely grant access to entire objects while failing to restrict which specific properties a user can read or modify (Palo Alto Networks, What Is Broken Object Property Level Authorization?). This is subtler than API1: you might correctly verify a user can see their own profile object, but forget that the response also includes an internal credit_limit field that shouldn't be exposed to that user at all — or worse, that the update endpoint lets them write to a field like role or isAdmin that they should never be able to touch.

API5 — Broken Function Level Authorization is the same failure at the level of entire endpoints rather than individual objects: an admin-only endpoint that works perfectly fine when called directly by a non-admin user, because the check for "is this user an admin" simply doesn't exist on that route.

All three come back to the same discipline covered in Part 1's identity layer: authorization has to be checked explicitly, on every request, at the resource level — never assumed from the fact that a request reached the server at all.

Rate Limiting and Resource Consumption — Where GCP's Native Tools Fit

API4, Unrestricted Resource Consumption, is where infrastructure-level controls do most of the work rather than application code — and it's where the GCP tooling landscape has two distinct answers depending on scale.

Google Cloud API Gateway handles authentication via API keys, OAuth 2.0, Google IAM, and custom JWT validation, along with request transformation, CORS handling, and — via integration or additional configuration — rate limiting, plus built-in logging to Cloud Operations and integration with Cloud Armor for DDoS protection and WAF rules (Zuplo, Google Cloud API Gateway guide). For most product teams putting a clean interface in front of Cloud Run services, this is the right starting point — it's lightweight and sits naturally alongside the load balancer and Cloud Armor setup from Part 1.

Apigee provides two distinct rate-limiting policy types: the SpikeArrest policy, which protects against traffic surges and sudden bursts that could indicate a denial-of-service attempt, and quota policies, which set usage limits based on client profiles and usage patterns to ensure no single application can negatively affect others sharing the API (Google Cloud, Apigee Rate-limiting documentation). Apigee becomes the right tool once an API stops being purely internal plumbing and starts being a product — partners consuming it, multiple client tiers with different limits, or a developer portal for external integrators.

A common and sensible pattern is to start on API Gateway and move to Apigee only once you begin selling API access or managing a portfolio of APIs across an organization (APIGatewayCost.com, Google Cloud API Gateway Pricing 2026). Don't reach for Apigee's full complexity on day one if API Gateway's simpler quota and auth model already covers what you actually need.

API7 (SSRF) and API8 (Security Misconfiguration): Where This Connects Back to Part 1

Two entries on this list aren't API-specific failures at all — they're the general web application concerns from Part 1, showing up again in an API context.

Server-Side Request Forgery happens when an API accepts a URL as input and then fetches it server-side — for a webhook configuration, an image import feature, anything that takes "give me a URL and I'll go get it." Without validation, an attacker can point that URL at your cloud provider's internal metadata endpoint or at private resources inside your VPC that were never meant to be reachable from outside. This is exactly why the VPC segmentation from Part 1 matters here too: even a successful SSRF attempt should hit a private subnet with nothing sensitive directly exposed, not a direct path to your database.

Security Misconfiguration, the same category that ranked #2 in the general OWASP Top 10 covered in Part 1, applies identically to APIs — overly permissive CORS policies, verbose error messages that leak stack traces, and default credentials left active on an API gateway are all instances of the same underlying problem: infrastructure set up quickly and never revisited.

Frequently Asked Questions

Is there a newer OWASP API Security Top 10 than the 2023 version?

No. There is no separate 2025 or 2026 edition — the 2023 release remains the current, authoritative version (AppSecMaster, OWASP API Security Top 10 guide). Any source claiming a distinct newer edition is either referencing the same 2023 list under a different label or is simply inaccurate.

What's the difference between Broken Authentication and Broken Object Level Authorization?

Authentication (API2) answers "who is this caller?" — verifying identity. Authorization (API1, API3, API5) answers "what is this specific, verified caller allowed to do or see?" A perfectly authenticated user — logged in correctly, valid token — can still trigger a BOLA vulnerability if the API never checks whether that authenticated user should be able to access the specific object they're requesting.

Should I use Google Cloud API Gateway or Apigee?

Use API Gateway when you need authentication, rate limiting via quotas, and routing in front of serverless backends at minimal cost. Use Apigee when you need API products, developer onboarding, monetization, or complex policy transformations across many teams (APIGatewayCost.com, 2026). Most internal or early-stage APIs are well served by API Gateway alone.

Does rate limiting alone prevent Unrestricted Resource Consumption attacks?

It's necessary but not sufficient. Setting usage limits and quotas based on client profiles safeguards an API from overwhelming request volumes, whether from simple errors like typos or from poorly designed systems making unnecessary calls (Trend Micro, GCP API Gateway rate limiting guidance) — but resource consumption also includes things like unbounded pagination, expensive queries with no complexity limits, and file upload endpoints with no size caps, all of which need their own specific guards beyond a simple requests-per-minute quota.

What's Next in This Series

APIs are one specific surface. The next post in this series turns to a surface with almost no security tooling built in by default: background processes and data pipelines — the workers and jobs that move data between systems with no user ever directly interacting with them, and no browser or API client to apply conventional defenses to at all.

If you're designing or reviewing an API architecture and want a second pair of eyes on the authorization model specifically, 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 2 of the Cloud Security series.

Sources

API SecurityOWASPGCPApigeeAPI GatewayOAuthRate LimitingCloud Security