I Spent a Week Learning How to Hack APIs and Honestly the Internet Should Be More Scared

Most people use apps every single day without thinking about what is happening underneath. You tap a button, data moves, something shows up on your screen. Simple right? Wrong. What is actually happening is an API call, and if that API is poorly built or poorly secured, someone like me, someone who just spent a week learning API penetration testing, could potentially do a lot of damage.

I am going through the Hacking API’s With Dami #HAWD program with Damilola Abiona and this week was all theory meets reality. Three courses, a lot of notes, and honestly more than a few moments where I sat back and thought “wait, this is really out here in production systems?”

Let me walk you through what I learned.

Before You Even Touch a Target The first thing API penetration testing teaches you is patience. Before you run a single tool or send a single request, you are supposed to understand what you are dealing with. This phase is called reconnaissance and it is where a lot of people cut corners and then wonder why they miss half the attack surface. Recon for APIs means hunting for documentation that was not meant to be public, finding exposed endpoints through Google dorking, checking GitHub repositories where developers accidentally committed API keys or swagger files, and looking at JavaScript files that sometimes contain endpoint paths the developers forgot to hide. Postman collections sometimes get leaked. API documentation sometimes lives on subdomains nobody thought to lock down. The attack surface for an API starts long before you send your first request. There are also things you need to clarify before testing even begins. What is in scope? Are there rate limits you need to work around? Do you have a test account? What is the baseline behavior of the API when everything is working normally? Understanding normal is what makes abnormal obvious.

During Testing, This Is Where It Gets Interesting API attack vectors are different from traditional web app attacks in ways that surprised me. Yes, there is overlap but APIs expose logic in a way that websites sometimes hide behind interfaces. Broken object level authorization, which we will get to in the OWASP section, is one of the most common things testers find. You are essentially asking the question, can I access objects that belong to other users just by changing an ID in a request? It sounds simple. It is devastatingly effective. Mass assignment is another one where APIs accept more parameters than they should and an attacker can send fields like “isAdmin: true” and the server just… accepts it. Testing also involves looking at how the API handles unexpected input, what happens when you send a string where it expects a number, what happens when you send a huge payload, what happens when you remove a required header. APIs fail loudly when they are not built with security in mind and that noise tells you exactly where the weaknesses are.

OWASP API Security Top 10, 2023 Edition The OWASP API Security Top 10 is essentially a greatest hits album of how APIs get compromised in the real world. The 2023 version updated some categories and added new ones based on what attackers are actually doing right now.

API1 is Broken Object Level Authorization. The Uber breach in 2022 involved an attacker accessing driver and rider data by manipulating object IDs in API requests. This is the number one finding for a reason.

API2 is Broken Authentication. This covers weak token validation, missing expiration on tokens, and APIs that accept credentials in URLs where they get logged. The 2021 Peloton API incident exposed user data partly because authentication on certain endpoints was not enforced properly.

API3 is Broken Object Property Level Authorization. This is where an API returns more data than the user should see. You make a request for your own profile and the response comes back with everyone else’s email addresses tucked in there too.

API4 is Unrestricted Resource Consumption. No rate limiting, no throttling, no caps. An attacker sends thousands of requests and either crashes the service or extracts a huge amount of data before anyone notices. The Venmo API at one point allowed anyone to pull millions of transactions publicly with no limits.

API5 is Broken Function Level Authorization. Regular users accessing admin endpoints because the API only checks if you are logged in, not what level of access you should have.

API6 is Unrestricted Access to Sensitive Business Flows. Think of an API for an e-commerce site that lets you place unlimited orders during a flash sale. No checks on whether that is humanly possible. Scalpers love this one.

API7 is Server Side Request Forgery. You get the API to make requests on your behalf to internal systems it should never be talking to. Capital One’s 2019 breach involved a variation of SSRF that exposed over 100 million customer records.

API8 is Security Misconfiguration. Default credentials left on, verbose error messages that reveal stack traces, unnecessary HTTP methods enabled, CORS configured too loosely. This one is embarrassingly common.

API9 is Improper Inventory Management. Old API versions still running in production, shadow APIs that nobody documented, endpoints built for a feature that got cancelled but never taken down. You cannot secure what you do not know exists.

API10 is Unsafe Consumption of APIs. Your API trusts data from third party APIs without validating it. The third party gets compromised and now so do you. This is the supply chain problem for APIs.

Authentication

The Part That Makes or Breaks Everything The authentication module this week was probably my favorite because it connected so much theory to real implementation. JWT (JSON Web Tokens) are everywhere. The structure is a header, payload, and signature separated by dots. JWTs have three parts and one of them tells the server what algorithm was used to sign the token, RS256, HS256 and so on. The signature is what stops someone from tampering with the token. But some libraries were written in a way that if you changed the algorithm field to “none” the server would skip signature verification entirely and just trust whatever was in the token. So an attacker could write “isAdmin: true” in their own token, set algorithm to none, and the server would accept it as legitimate. No forgery skill needed, This has CVE’s like CVE-2015–9235 , a documented case of this in the jsonwebtoken library.

OAuth 2.0 is the framework behind “Sign in with Google” and similar flows. It involves authorisation codes, access tokens, refresh tokens, and scopes. The attack surface here includes open redirects in the redirect URI, token leakage through referrer headers, and CSRF attacks on the authorisation flow. Facebook’s 2018 breach that exposed 50 million accounts involved a flaw in their OAuth implementation and the “View As” feature.

API keys sound simple but they carry their own risks. They get committed to GitHub by accident constantly. There are tools that just scan GitHub for exposed API keys and find them every single day. Rotation policies, scope limitations, and monitoring for unusual usage patterns are all things that should come with every API key implementation but often do not. Basic auth, session tokens, certificate based auth, each comes with trade-offs and each comes with a way to abuse it if the implementation is careless.

What This Week Actually Taught Me Security is not something you bolt onto a product after you build it. It has to live in every decision made during design and development. The attacks I studied this week are not exotic. They are not the work of criminal masterminds. Most of them come from developers who were moving fast and not thinking about what happens when someone uses their API in ways it was not designed for. Learning to break things teaches you how to build things better. That is the whole point of this program and one week in I am already looking at every app I use differently.

Next stop, Vulnerable API Labs. Time to put all of this to work.

References APIsec University. (2024). Getting Started in API Penetration Testing. https://www.apisecuniversity.com/courses/getting-started-in-api-pen-testing APIsec University. (2024). OWASP API Security Top 10 and Beyond. https://www.apisecuniversity.com/courses/owasp-api-security-top-10 APIsec University. (2024). API Authentication. https://www.apisecuniversity.com/courses/api-authentication OWASP. (2023). OWASP API Security Top 10 2023. https://owasp.org/API-Security/editions/2023/en/0x00-header/ PortSwigger. (2024). JWT Attacks. https://portswigger.net/web-security/jwt