# Export your API endpoints to Postman or OpenAPI, then test them

Published: 2026-11-10 · Updated: 2026-11-03 · By HackerGPT Team
Canonical: https://hackergpt.org/blog/export-api-endpoints-postman-openapi/

> You have a list of every API endpoint with its auth requirement. Here is how to export it to Postman or OpenAPI and turn it into an auth test plan, with a script run on CyberGym.

**TL;DR:** Export the endpoint list to OpenAPI when you want a description to check against, and to Postman when you want requests to replay; Postman can turn an OpenAPI file into a collection, so one export serves both. Then test the auth column, not the list: call every endpoint with no session, with your own session, and with your session against another user's object, and compare each result with the auth the endpoint is supposed to require.

This article is for app owners and learners who already have an inventory of their app's API endpoints, from [AppMap](https://hackergpt.org/features/appmap/) or built by hand, and are asking what to do with it. You will learn what an endpoint export contains, when to pick Postman or OpenAPI, and how to turn the export into a repeatable auth test, with a short script we ran against [CyberGym](https://cybergym.hackergpt.app), a legal practice target.

[Watch on YouTube: Map every API endpoint on a web app in one minute (state graph + Postman export)](https://www.youtube.com/watch?v=UFZ15BOdhdg)

The short video above shows the mapping step: HackerGPT crawls CyberGym into a state graph, then shows the API map with each request, endpoint and authorization token. How to build that inventory in the first place is covered in [Map a web app's attack surface before you test it](https://hackergpt.org/blog/map-web-app-attack-surface/). Run everything below only against apps you own or have written permission to test.

## What is in an API endpoint export?

An endpoint export is your app's API as a file: each endpoint's method and path, its parameters, and the authentication it requires. The last field is the one that matters for security, because the interesting bugs live in the gap between the auth an endpoint should require and the auth it actually checks.

The two common formats hold this differently:

|  | OpenAPI description | Postman collection |
| --- | --- | --- |
| What it is | A specification of the API: paths, operations, parameters, schemas, security | A set of saved requests, grouped, with variables for host and tokens |
| Best for | Checking the API against what you meant to build; feeding other tools | Replaying and modifying requests by hand or in a test run |
| Auth | Declared per operation with `security`, or inherited from the top level | Set per request or per folder, usually a token variable |

You do not have to choose once: Postman imports an OpenAPI specification and can bring it in as a Postman Collection ([Postman, Importing data](https://learning.postman.com/docs/getting-started/importing-and-exporting/importing-data/)).

## How does OpenAPI describe which endpoints need auth?

OpenAPI declares auth with a top-level `security` list that applies to every operation, and lets each operation override it. The specification is explicit: an operation's `security` "overrides any declared top-level security", and "to remove a top-level security declaration, an empty array can be used" ([OpenAPI Specification 3.1.0](https://spec.openapis.org/oas/v3.1.0.html)). So in a description where the top level requires a bearer token, `"security": []` on an operation means "public".

That makes the description a list of claims you can check. Here is a partial description of seven CyberGym GET endpoints that we wrote by hand for this article, with the auth we would *expect* each to require. It stands in for an export:

```json
{
  "openapi": "3.1.0",
  "info": { "title": "CyberGym (partial, hand-written)", "version": "19.1.1" },
  "servers": [{ "url": "https://cybergym.hackergpt.app" }],
  "components": {
    "securitySchemes": { "bearerAuth": { "type": "http", "scheme": "bearer" } }
  },
  "security": [{ "bearerAuth": [] }],
  "paths": {
    "/api/Products": { "get": { "security": [] } },
    "/rest/products/search": { "get": { "security": [] } },
    "/rest/memories": { "get": { "security": [] } },
    "/rest/basket/1": { "get": {} },
    "/api/Cards": { "get": {} },
    "/api/Users": { "get": {} },
    "/rest/admin/application-configuration": { "get": {} }
  }
}
```

The product list, search and the Photo Wall (`/rest/memories`) are public pages, so we marked them public. Baskets, cards, the user list and anything under `/rest/admin/` we marked as needing a session.

## How do I test the auth column of the export?

Test it by sending each endpoint the request its declaration says should fail, and recording what comes back. The first column is the cheapest: no session at all. Save the description above as `cybergym-openapi.json` and run:

```bash
BASE=https://cybergym.hackergpt.app
jq -r '.paths | to_entries[] | .key as $p | .value | to_entries[]
  | select(.key == "get")
  | "\($p) \(if .value.security == [] then "public" else "auth" end)"' cybergym-openapi.json |
while read -r ep declared; do
  code=$(curl -s -o /dev/null -w '%{http_code}' "$BASE$ep")
  printf '%-40s declared=%-7s anonymous=%s\n' "$ep" "$declared" "$code"
done
```

It sends only GET requests and no credentials. On 2 November 2026 it printed:

```text
/api/Products                            declared=public  anonymous=200
/rest/products/search                    declared=public  anonymous=200
/rest/memories                           declared=public  anonymous=200
/rest/basket/1                           declared=auth    anonymous=401
/api/Cards                               declared=auth    anonymous=401
/api/Users                               declared=auth    anonymous=401
/rest/admin/application-configuration    declared=auth    anonymous=200
```

Six lines match the declaration. The last does not: an endpoint under `/rest/admin/` returns `200` to a request with no session. That is a line item, not yet a finding. The configuration may be meant to be public; the export made you decide.

![Auth test matrix for seven CyberGym endpoints: declared auth versus the observed anonymous status, two cells flagged](https://hackergpt.org/blog/export-api-endpoints-postman-openapi/auth-matrix.webp)

*The anonymous column is what we observed on CyberGym. The other columns need two test accounts of your own.*

### Check what a public endpoint returns, not only that it answers

A `200` on a public endpoint can still be wrong. The Photo Wall is public by design, but look at the field names in its response:

```bash
curl -s https://cybergym.hackergpt.app/rest/memories | jq -c '[.data[0] | keys, (.User | keys)]'
```

```text
[["User","UserId","caption","createdAt","id","imagePath","updatedAt"],["createdAt","deletedAt","deluxeToken","email","id","isActive","lastLoginIp","password","profileImage","role","totpSecret","updatedAt","username"]]
```

The page shows a photo and a caption. The API returns the uploader's whole account record, with fields named `password` and `totpSecret`, to anyone. OWASP calls this [Broken Object Property Level Authorization (API3:2023)](https://owasp.org/API-Security/editions/2023/en/0xa3-broken-object-property-level-authorization/), which merges the 2019 entries "Excessive Data Exposure" and "Mass Assignment", and this response is the Excessive Data Exposure half. In an OpenAPI description you would catch it by giving the operation a response schema and comparing real responses against it.

### Then add the session columns

The anonymous column catches missing authentication. The next two catch missing authorization, and they need two test accounts you create yourself:

1. **As user A, on user A's objects.** Confirms the endpoint works with a session. In Postman, set the token as a collection variable and run the whole collection.
2. **As user A, on user B's objects.** Change only the id in the path. If it returns B's data, that is [Broken Object Level Authorization (API1:2023)](https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/). The [IDOR example](https://hackergpt.org/blog/idor-vulnerability-example/) walks through this exact check on CyberGym's basket endpoint.
3. **As a normal user, on admin functions.** Any endpoint meant for a role should refuse a session without it, which is [Broken Function Level Authorization (API5:2023)](https://owasp.org/API-Security/editions/2023/en/0xa5-broken-function-level-authorization/).

Postman's command-line runner, Newman, runs a collection from the terminal, so the same matrix can run after every deploy ([Postman, Newman](https://learning.postman.com/docs/collections/using-newman-cli/command-line-integration-with-newman/)).

## What does an endpoint export not cover?

An export covers the endpoints the crawl reached, so it inherits the crawl's blind spots: endpoints the interface never calls, old API versions still running, and functions only a role you did not log in as can see. OWASP lists unknown and outdated endpoints as their own risk, [Improper Inventory Management (API9:2023)](https://owasp.org/API-Security/editions/2023/en/0xa9-improper-inventory-management/). Keep the export as a dated inventory, regenerate it after each release, and diff the two: a new endpoint nobody decided to add is worth a look.

It also does not judge business logic. A matrix of status codes tells you who can call an endpoint, not whether what it does is safe. That is the testing that comes after, by you or with HackerGPT.

## Key takeaways

- Export to OpenAPI for a checkable description and to Postman for replay; Postman can import one from the other.
- In OpenAPI, `"security": []` on an operation marks it public; everything else inherits the top-level requirement, so each line is a claim to test.
- Run the anonymous column first: one GET per endpoint with no session, compared against the declared auth.
- Read the response fields of public endpoints, not just their status codes; over-sharing is a finding of its own.
- Add the user-A and user-B columns with test accounts you own, and regenerate and diff the export every release.

## FAQ

### How do I find all the API endpoints of my web app?

Combine a crawl that holds a session, so it sees past the login, with a read of the front end's JavaScript and the browser's network log. No method finds every endpoint for certain, especially ones the interface never calls. Treat the result as an inventory with known gaps, and re-run it after each release.

### Can I generate an OpenAPI spec from a website?

You can generate one from what the site's front end calls: a crawler records the requests and writes them as an OpenAPI description. It describes the API as observed, not as designed, so compare it with what you intended to expose. AppMap exports the endpoints it reached to OpenAPI or Postman.

### Postman or OpenAPI: which export should I use?

Use OpenAPI when you want a description to check against your intended API or feed other tools, and Postman when you want to replay and modify requests. Postman can import an OpenAPI file as a collection, so many people keep the OpenAPI file as the source and work in Postman.

### How do I test whether an API endpoint needs authentication?

Send it the request with no credentials and read the status code: `401` or `403` means it refused, `200` means it answered. Then repeat with your own session on another user's object id, which tests authorization rather than authentication. Only do this on apps you own or have written permission to test.

## Sources

- [OpenAPI Specification 3.1.0 — Security Requirement Object](https://spec.openapis.org/oas/v3.1.0.html)
- [Postman — Importing data (OpenAPI to collection)](https://learning.postman.com/docs/getting-started/importing-and-exporting/importing-data/)
- [Postman — Run collections with Newman](https://learning.postman.com/docs/collections/using-newman-cli/command-line-integration-with-newman/)
- [OWASP API Security Top 10 2023 — API1 Broken Object Level Authorization](https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/)
- [OWASP API Security Top 10 2023 — API3 Broken Object Property Level Authorization](https://owasp.org/API-Security/editions/2023/en/0xa3-broken-object-property-level-authorization/)
- [OWASP API Security Top 10 2023 — API5 Broken Function Level Authorization](https://owasp.org/API-Security/editions/2023/en/0xa5-broken-function-level-authorization/)
- [OWASP API Security Top 10 2023 — API9 Improper Inventory Management](https://owasp.org/API-Security/editions/2023/en/0xa9-improper-inventory-management/)

Map and export your own app's endpoints with [HackerGPT](https://hackergpt.app), or practise the method on [CyberGym](https://cybergym.hackergpt.app).