Bypass Restrictions in API Gateway

What this lab covers

You examine an API fronted by Amazon API Gateway, work out what its resource policy actually permits as opposed to what it appears to permit, and modify and deploy configuration to demonstrate the difference.

The lab covers the part of API security that is specific to the platform rather than to the application. Authentication and input validation matter, but in cloud-hosted APIs the gateway's own policy layer decides who reaches the application at all.

It suits anyone assessing or building APIs on AWS and assumes no prior gateway experience.

How API Gateway access control works

API Gateway sits between clients and backend services and applies several independent layers: the endpoint type, which decides whether the API is reachable from the internet at all, the resource policy, which states which principals and sources may invoke it, and authorisation on individual methods.

These layers are evaluated together, and confusion between them is where mistakes arise. A private endpoint restricts network reachability, a resource policy restricts principals and source addresses, and neither substitutes for the other. Teams frequently assume one is doing the work of the other.

The deployment model is the crucial detail. Changes to an API are not live until the stage is deployed, so configuration can be saved and appear correct in the console while the deployed stage continues serving the previous behavior. Anyone reviewing the console sees the intended state, not the effective one.

How to detect this in your own environment

Alert on resource policy changes and on stage deployments, both of which are management events recorded by default. A deployment immediately following a policy change by an unexpected principal is the pattern worth flagging.

Enable access logging on stages, which is not on by default. Without it you have management-plane visibility into configuration but no record of who invoked the API, which is the same read-versus-configure blind spot that appears across AWS.

Reconcile deployed configuration against intended configuration on a schedule. Because saved and deployed can diverge silently, the only reliable check is to inspect the deployed stage rather than the console view.

How to prevent it

Use the right endpoint type first. If an API should only be reachable from inside your network, a private endpoint enforces that at the network layer, which is a stronger and simpler control than expressing the same intent as a source address condition in a policy.

Write resource policies that deny by default and allow specific principals or sources, rather than allowing broadly and denying exceptions. Deny-by-default fails closed when someone adds a new consumer without thinking.

Treat API configuration as code and deploy it through a pipeline. That removes the saved-versus-deployed divergence entirely, because the deployed state is whatever is in the repository.

Real-world context

APIs have become the dominant attack surface for cloud-hosted applications, largely because they expose functionality directly with fewer of the incidental protections that surround traditional web interfaces. Industry reporting has repeatedly identified API-related exposure as a leading cause of cloud data incidents.

Gateway misconfiguration is particularly consequential because it sits in front of everything. An authorisation flaw in one endpoint affects one endpoint, whereas a resource policy that does not restrict what it appears to restrict affects the whole API.

The pattern maps to MITRE ATT&CK T1190 Exploit Public-Facing Application and T1133 External Remote Services.

Applying this at work

• Inventory your APIs by endpoint type and confirm each internet-facing one is deliberately so.
• Compare deployed stage configuration against intended configuration, rather than reviewing the console view.
• Enable access logging on production stages so invocations are attributable.
• Rewrite resource policies that allow broadly and deny exceptions, into deny-by-default policies.
• Move API configuration into your deployment pipeline so saved and deployed cannot diverge.

Frequently asked questions

Why do API Gateway changes not take effect immediately?

Because changes apply to a stage only when that stage is deployed. Configuration can be saved and look correct while the deployed stage continues serving the previous behavior, so the console view may not reflect what is actually enforced.

What is the difference between a private endpoint and a resource policy?

A private endpoint controls network reachability, restricting the API to your internal network. A resource policy controls which principals and source addresses may invoke it. They operate at different layers and neither replaces the other.

Is API Gateway access logged by default?

Management operations such as configuration changes are recorded by default, but stage access logging is not enabled automatically. Without it you cannot attribute individual API invocations.

Do I need my own AWS account to practice this?

No. The lab runs in a live AWS environment that Pwned Labs provisions for you, so there is nothing to set up and no risk to your own infrastructure.

Which certification covers this in depth?

The Amazon Cloud Red Team Professional (ACRTP) covers AWS service configuration abuse and privilege escalation in full, and is assessed hands-on in a live AWS account.