API Security Testing: Auth, Encryption & Vulnerabilities

API Security Testing: OWASP Top 10 Checks With Postman Tests

APIs expose data and actions directly, without a UI to hide behind — which makes them a favourite target for attackers. API security testing checks that only the right people can reach the right data, that inputs can't break or trick the server, and that responses don't leak more than they should.

This guide covers what to test, organised around the OWASP API Security Top 10, how to test it as a QA engineer, and a set of Postman checks that were run with Newman against a test API — all 10 assertions passed.

Important: run security tests only against environments you're authorised to test — never against production or third-party APIs without written permission.

What API Security Testing Covers

The OWASP API Security Top 10 (2023) for Testers

BOLA is one of the most important API authorization flaws to test — log in as user A and verify that user A cannot access user B's resources.

Security Checks in Postman

This collection ran against a test API with two users (tok-asha for user 1, and an admin token). Each request is shown with its Post-response tests.

Authentication — Missing and Forged Tokens

// GET /users/1 — no Authorization header

pm.test(
  '401 without a token',
  () => pm.response.to.have.status(401)
);

// GET /users/1 — Authorization: Bearer tok-forged

pm.test(
  '401 with a forged token',
  () => pm.response.to.have.status(401)
);

Excessive Data Exposure

// GET /users/1 — as user 1 (own record)

const user = pm.response.json();

pm.test(
  '200 for own record',
  () => pm.response.to.have.status(200)
);

pm.test(
  'no sensitive fields exposed',
  () => pm.expect(user).to.not.have.any.keys(
    'password',
    'passwordHash',
    'ssn'
  )
);

BOLA — Another User's Record

// GET /users/2 — still logged in as user 1

pm.test(
  "403 for someone else's record",
  () => pm.expect(pm.response.code).to.be.oneOf([403, 404])
);

The key idea is that changing an object ID should not allow one authenticated user to access another user's data.

Function-Level Authorisation

// GET /admin/reports — as a normal user

pm.test(
  '403 for a normal user on an admin endpoint',
  () => pm.response.to.have.status(403)
);

Injection Input

// GET /users/1%20OR%201=1

pm.test(
  'rejected with 4xx — never 200 or 500',
  () => pm.expect(pm.response.code).to.be.oneOf([400, 404])
);

pm.test(
  'no database error leaked',
  () => pm.expect(pm.response.text())
    .to.not.match(/SQL|syntax|ORA-|stack/i)
);

A 200 could indicate that the injection changed the query. A 500 could mean the input reached a backend component unexpectedly and caused an error. Both behaviours deserve investigation.

Misconfiguration — Methods and Headers

// DELETE /users/1 — method not offered to this user

pm.test(
  '405 for an unsupported method',
  () => pm.response.to.have.status(405)
);

// Any response

pm.test('security headers present', () => {
  pm.response.to.have.header(
    'X-Content-Type-Options',
    'nosniff'
  );

  pm.response.to.have.header(
    'Strict-Transport-Security'
  );

  pm.response.to.have.header(
    'Cache-Control',
    'no-store'
  );
});

Run as a collection, all 10 assertions passed.

Put common header checks in the collection-level script so every response is checked.

Token handling and role matrices in more depth: Postman Token Handling.

More Test Ideas by Area

Authentication

• Expired tokens, tokens with the signature changed, tokens with alg: none, tokens from another environment.
• Account lockout or throttling after repeated failed logins.
• Password reset links that expire, work only once, and don't reveal whether an email is registered.

Mass Assignment

PATCH /users/1

{
  "name": "Asha",
  "role": "admin",
  "balance": 1000000
}

The API should ignore or reject fields a user may not set.

Then retrieve the record and confirm that protected fields such as role and balance were not changed.

Input Validation

Test potentially dangerous or malformed input in authorised test environments:

• SQL injection strings such as ' OR '1'='1
• Script tags such as <script>alert(1)</script>
• Path traversal such as ../../etc/passwd
• Wrong data types
• Very large strings
• Deeply nested JSON
• Unexpected Content-Types

The expected behaviour depends on the endpoint, but malformed or malicious input should not result in unintended access, data exposure or uncontrolled server errors.

Transport and Data

• HTTP requests should be rejected or redirected to HTTPS according to the application's security policy.
• TLS should use current, supported configurations.
• Tokens and personal data should never appear unnecessarily in URLs because URLs can be captured in logs and monitoring systems.
• Sensitive information should not appear in error messages or stack traces.
• Personal data should be masked where the client does not need the complete value.

Abuse Limits

• Rapid repeated requests should eventually return 429 Too Many Requests where rate limiting is part of the API's security design.
• Check whether a Retry-After header is provided where appropriate.
• Page sizes should be capped.
• Payload and upload sizes should be limited.

Plan security cases alongside functional cases for each endpoint in the API Testing Scenario Lab.

Tools

QA-owned checks can catch logic flaws that automated scanners may not identify, such as BOLA, mass assignment and business-flow authorization issues. Dedicated security testing and penetration tests can go deeper.

Automating core checks in CI means a regression in access control can become a visible build failure.

See API Testing in CI/CD.

From Real Projects

I've worked with APIs at the level this page covers: CRUD operations, HTTP methods, JSON and XML formats, and extracting and validating values with JSON path. A good habit from that work: test the full create–read–update–delete cycle for a resource and check each response in detail. Testsigma supports web, mobile and API test automation, so understanding APIs was part of understanding the product I was testing. Always test what happens when one user tries to access another user's data.

📚 Official documentation: OWASP Top 10 · MDN: HTTP

FAQs

What is API security testing?

Testing that an API allows only authorised access, handles malicious or malformed input safely, and doesn't expose sensitive data. This includes authentication, authorisation, input validation, data exposure, transport and abuse controls.

What is BOLA?

Broken Object Level Authorization (BOLA) occurs when a user can access another user's object or resource by changing an identifier.

A common test is to authenticate as user A and request an object belonging to user B. The API should enforce the appropriate authorization rule.

401 or 403?

• 401: the caller is not successfully authenticated, such as when a token is missing, invalid or expired.
• 403: the caller is authenticated but is not permitted to perform the requested operation.

The exact status behaviour should follow the API's documented contract.

How do you test SQL injection in an API?

Send controlled injection test strings through authorised test environments in path, query and body fields. The API should safely handle the input without returning unintended data, database error details or uncontrolled server errors.

Can Postman do security testing?

Yes. Postman is useful for repeatable API security checks such as authentication, authorization, headers, validation and negative scenarios.

Tools such as OWASP ZAP or Burp Suite can be used for broader scanning and deeper security testing.

Which headers should an API return?

The appropriate headers depend on the application and deployment architecture. Common security-related controls include Strict-Transport-Security, X-Content-Type-Options: nosniff, suitable Cache-Control directives for sensitive responses, and an appropriately restrictive CORS policy.

Related

• API Authentication: OAuth & JWT
• REST Assured Authentication
• Non-Functional Testing
• The Complete API Testing Tutorial