Postman API Security Testing

Every API protects some kind of data: accounts, orders, messages, or payments. Security testing verifies that the protection holds. Postman helps teams run repeatable defensive checks against APIs they own. Run these tests only on systems you built or have written permission to test.

The House Inspection Picture

A home inspector checks locks, windows, and smoke alarms before a family moves in. The inspector does not break into other people's houses. API security testing follows the same spirit: inspect your own doors and fix weak locks before anyone else finds them.

  OWN API
  ├── Front door      → authentication      (who are you?)
  ├── Room keys       → authorization       (what may you open?)
  ├── Windows         → input validation    (what do you send me?)
  ├── Alarm           → rate limiting       (how often do you knock?)
  └── Curtains        → data exposure       (what do I reveal?)

Core Security Areas

Area	Question to Answer
Authentication	Does the API reject callers without valid credentials?
Authorization	Can one user reach another user's data?
Input validation	Does the API reject malformed and oversized input cleanly?
Rate limiting	Does the API slow down excessive callers?
Data exposure	Do responses leak fields that callers should never see?
Transport security	Does the API require HTTPS and send safe headers?

The OWASP API Security Top 10 is a respected public list of common API risks. Use it as a checklist when you plan tests.

Test 1: Authentication Is Required

Send a protected request with no token, with an expired token, and with a random value. Every call must fail.

pm.test("Request without token is rejected", function () {
    pm.expect(pm.response.code).to.be.oneOf([401, 403]);
});

pm.test("Error body reveals no internal details", function () {
    const text = pm.response.text();
    pm.expect(text).to.not.include("stack");
    pm.expect(text).to.not.include("Exception");
});

Test 2: Users Stay in Their Own Lane

Broken object-level authorization is a leading API risk. Log in as user A, then request a record that belongs to user B. The API must refuse.

  User A token  ──►  GET /orders/1001   (A's own order)   → 200 expected
  User A token  ──►  GET /orders/2002   (B's order)        → 403 or 404 expected

pm.test("Other user's order is not accessible", function () {
    pm.expect(pm.response.code).to.be.oneOf([403, 404]);
});

Use two test accounts that you created for this purpose.

Test 3: Input Validation

Send unusual but harmless input and watch the server reaction: an empty field, a number where text belongs, a very long string, and a missing required field. A well-built API answers with a 400 or 422 status and a clear message. A 500 status signals that the server did not handle the input safely.

pm.test("Bad input returns a client error, not a server error", function () {
    pm.expect(pm.response.code).to.be.within(400, 499);
});

Data driven runs make this efficient: place each odd input in a CSV file and let the Collection Runner repeat the request.

Test 4: Rate Limiting

Send a burst of requests from the Collection Runner against a test environment. A protected API eventually answers with status 429 and often includes a Retry-After header.

pm.test("Rate limit headers exist", function () {
    pm.expect(pm.response.headers.has("Retry-After") ||
              pm.response.code !== 429).to.be.true;
});

Test 5: No Sensitive Data in Responses

pm.test("Response hides sensitive fields", function () {
    const user = pm.response.json();
    pm.expect(user).to.not.have.property("password");
    pm.expect(user).to.not.have.property("passwordHash");
    pm.expect(user).to.not.have.property("internalNotes");
});

Test 6: Transport and Headers

pm.test("Security headers are present", function () {
    pm.expect(pm.response.headers.has("Strict-Transport-Security")).to.be.true;
    pm.expect(pm.response.headers.has("X-Content-Type-Options")).to.be.true;
});

Confirm that plain HTTP requests redirect to HTTPS or get refused.

Safe Testing Rules

• Test only systems you own or have written permission to test.
• Use a staging environment with fake data.
• Tell teammates before running bursts of requests.
• Store test credentials in the vault, and delete them after the exercise.
• Report findings privately to the API owner and fix them before publishing details.

Automate the Checks

Group the security tests into one folder named Security Checks. Run the folder in Newman or Postman CLI for every release. A security regression then stops the build as quickly as a functional bug.

Key Points

• Security testing verifies authentication, authorization, input handling, limits, and data exposure.
• Two test accounts reveal whether users can see each other's records.
• A 500 error after odd input signals weak validation.
• Response tests can confirm that sensitive fields never leave the server.
• Test only systems you own or have permission to test.