Postman Tests and Scripts: Assertions, Chaining and Newman CLI

Clicking Send and reading the response is manual testing. The moment you add a script that checks the status, the body and the headers on its own, your Postman collection becomes an automated test suite. Add Newman and it runs every night in CI without anyone opening Postman. This lesson covers the pm scripting API, the assertions you’ll use daily, JSON Schema validation, chaining, data-driven runs and Newman with HTML reports, all on the live practice API.

Pre-request vs Post-response Scripts

The Assertions You’ll Use Every Day

// Status
pm.test('status is 200', () => pm.response.to.have.status(200));
pm.test('status is 2xx', () => pm.response.to.be.success);
pm.test('status is one of 200/201', () => pm.expect(pm.response.code).to.be.oneOf([200, 201]));

// Response time
pm.test('responds under 1000 ms', () => pm.expect(pm.response.responseTime).to.be.below(1000));

// Headers
pm.test('JSON content type', () => {
  pm.expect(pm.response.headers.get('Content-Type')).to.include('application/json');
});
pm.test('has ETag', () => pm.response.to.have.header('ETag'));

// Body values
const json = pm.response.json();
pm.test('user is Asha Verma', () => {
  pm.expect(json.data.name).to.eql('Asha Verma');
  pm.expect(json.data.age).to.be.a('number').and.to.be.above(17);
  pm.expect(json.data.role).to.be.oneOf(['admin', 'editor', 'viewer']);
  pm.expect(json.data.email).to.match(/^[^@\s]+@[^@\s]+$/);
});

// Arrays
pm.test('every product is a book', () => {
  json.data.forEach(p => pm.expect(p.category).to.eql('books'));
});

// Negative / error format
pm.test('error has code and message', () => {
  pm.expect(json.error).to.have.all.keys('status', 'code', 'message');
});

Try the last pattern on a 404 response:

curl -i \
  "https://sqatools.in/wp-json/sqa-api/v1/users/999"

JSON Schema Validation in Postman

Postman includes a JSON Schema validator. Validate the whole structure in one assertion:

const userSchema = {
  type: 'object',
  required: ['id', 'name', 'email', 'role', 'age', 'active'],
  properties: {
    id:     { type: 'integer', minimum: 1 },
    name:   { type: 'string' },
    email:  { type: 'string' },
    role:   { enum: ['admin', 'editor', 'viewer'] },
    age:    { type: 'integer', minimum: 18 },
    active: { type: 'boolean' },
  },
};

// Built-in assertion: wrap the user schema because the API returns { "data": user }
pm.test('user matches schema', () => {
  pm.response.to.have.jsonSchema({ type: 'object', required: ['data'], properties: { data: userSchema } });
});

// Same check with the bundled Ajv library (shows detailed errors):
pm.test('user matches schema (Ajv)', () => {
  const Ajv = require('ajv');
  const ajv = new Ajv({ allErrors: true });
  pm.expect(ajv.validate(userSchema, pm.response.json().data), JSON.stringify(ajv.errors)).to.be.true;
});

Tip: the practice API publishes its real contract at GET /schema/user. Fetch it once, store it in a collection variable, and validate every user response against it.

Chaining Requests: A Full CRUD Flow

Create a folder “CRUD flow” with five requests and these scripts:

Controlling the flow

// Skip the rest of the run if login failed
if (pm.response.code !== 200) {
  pm.execution.setNextRequest(null);          // older versions: postman.setNextRequest(null)
}

// Jump to a specific request by name
pm.execution.setNextRequest('Cleanup - delete object');

Pre-request Scripts: Get a Token Automatically

Put this at collection level so every request has a valid token, fetched only when the old one is missing or expired:

const expiresAt = pm.collectionVariables.get('token_expires_at');
if (!expiresAt || Date.now() > Number(expiresAt) - 30000) {
  pm.sendRequest({
    url: pm.environment.get('baseUrl') + '/auth/login',
    method: 'POST',
    header: { 'Content-Type': 'application/json' },
    body: { mode: 'raw', raw: JSON.stringify({
      username: pm.environment.get('username'),
      password: pm.environment.get('password'),
    }) },
  }, (err, res) => {
    const body = res.json();
    pm.collectionVariables.set('access_token', body.access_token);
    pm.collectionVariables.set('token_expires_at', Date.now() + body.expires_in * 1000);
  });
}

Then set the collection’s Authorization to Bearer Token = {{access_token}}.

Data-Driven Testing with the Collection Runner

Run one request many times with different inputs from a CSV or JSON file. Example age-boundaries.csv for POST /validate/user:

name,email,age,expectedStatus
Asha,asha@example.com,17,422
Asha,asha@example.com,18,200
Asha,asha@example.com,100,200
Asha,asha@example.com,101,422

Request body uses data variables:

{ "name": "{{name}}", "email": "{{email}}", "age": {{age}} }

Test script reads the expected value from the same row:

pm.test(`age ${pm.iterationData.get('age')} -> ${pm.iterationData.get('expectedStatus')}`, () => {
  pm.response.to.have.status(Number(pm.iterationData.get('expectedStatus')));
});

In the Runner, select the request or folder, choose the data file, check the preview and click Run. Each CSV row is one iteration.

curl -i \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"name":"Asha","email":"asha@example.com","age":17}' \
  "https://sqatools.in/wp-json/sqa-api/v1/validate/user"

Newman: Run Postman Collections from the Command Line

Newman is Postman’s command-line runner. It’s how collections run in Jenkins, GitHub Actions, GitLab CI or Azure DevOps.

# 1. Install (needs Node.js)
npm install -g newman newman-reporter-htmlextra

# 2. Export from Postman: collection (v2.1) and environment as JSON files

# 3. Run
newman run sqa-practice.postman_collection.json \
  -e sqa-practice.postman_environment.json \
  -d age-boundaries.csv \
  -r cli,junit,htmlextra \
  --reporter-junit-export results/junit.xml \
  --reporter-htmlextra-export results/report.html

# Useful options
#   --folder "CRUD flow"     run one folder only
#   -n 3                     run 3 iterations
#   --delay-request 200      wait 200 ms between requests
#   --bail                   stop on first failure
#   --env-var "password=$QA_PASSWORD"   inject secrets from CI

Newman exits with code 1 when any test fails, which fails the CI build: exactly what you want.

Newman in GitHub Actions

name: api-tests
on: [push, workflow_dispatch]
jobs:
  newman:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20 }
      - run: npm install -g newman newman-reporter-htmlextra
      - run: |
          newman run postman/sqa-practice.postman_collection.json \
            -e postman/sqa-practice.postman_environment.json \
            --env-var "password=${{ secrets.QA_PASSWORD }}" \
            -r cli,htmlextra --reporter-htmlextra-export report.html
      - uses: actions/upload-artifact@v4
        if: always()
        with: { name: newman-report, path: report.html }

Organising a Maintainable Postman Test Suite

• Folders per resource, plus “Smoke”, “Negative” and “Flows”.
• Reusable checks at collection level, e.g. a post-response script asserting every response is JSON and under 2 seconds.
• Names that state the expectation: “PATCH object with stale If-Match – 412”.
• No hardcoded ids or URLs; everything via variables.
• Each flow creates and cleans up its own data.
• Collections stored in Git (exported JSON) so changes are reviewed.

Reusable code across requests can be saved as a function in a collection variable or, in recent Postman versions, as package library scripts.

Postman vs Code-Based Automation

Many teams use both: Postman for exploration and contract smoke tests, Playwright for the main regression suite (Module 6).

Interview Questions: Postman Scripts and Newman

Postman Tutorial for Beginners: API Testing Step by Step

Postman is the tool most testers open first when a developer says “the API is ready”. It lets you send any request in seconds, save it, share it with the team and later turn it into automated tests. In this Postman tutorial you’ll go from installation to a complete, reusable collection for a real API, with environments, variables, authentication and request chaining, using the free SQA Tools practice API at every step.

Why Testers Use Postman

• No code needed to start: fill in method, URL and body, click Send.
• Organised: collections and folders mirror the API structure; everyone uses the same requests.
• Reusable: variables and environments mean one collection works on dev, QA and staging.
• Testable: JavaScript test scripts turn requests into automated checks.
• Shareable: export collections as JSON, share workspaces, generate documentation.
• CI-ready: Newman runs collections from the command line in Jenkins or GitHub Actions.

Install Postman and Understand the Interface

1. Download the desktop app from postman.com (Windows, macOS, Linux) or use the web version. A free account syncs your work.
2. Create a workspace (personal or team) for your project.

Send Your First Request

1. Click New → HTTP (or the + tab).
2. Method: GET. URL: https://sqatools.in/wp-json/sqa-api/v1/users
3. Click Send. Check status 200 OK, time and size in the response panel.
4. Open the Headers tab of the response: find X-Total-Count: 12 and the Link header.

Here’s the same request in your browser to compare:

curl -i \
  "https://sqatools.in/wp-json/sqa-api/v1/users?role=admin"

Query parameters with the Params tab

Instead of typing ?role=admin&sort=age, add rows in Params: key role value admin, key sort value age. Postman builds and encodes the URL. Untick a row to disable it temporarily: handy for negative tests.

POST with a JSON Body

1. New request, method POST, URL https://sqatools.in/wp-json/sqa-api/v1/objects
2. Body → raw → JSON, then paste:

   {
     "name": "Postman test object",
     "data": { "color": "blue", "qty": 3 },
     "ttl": 300
   }

3. Send. Expect 201 Created. Postman added Content-Type: application/json automatically (see the hidden headers in the Headers tab).
4. Copy the id from the response; you’ll use it next with PUT, PATCH and DELETE.

Collections: Organise Your Requests

A collection is a folder of saved requests, with shared variables, auth and scripts.

1. Click Collections → + and name it “SQA Practice API”.
2. Add folders: Users, Products, Objects CRUD, Auth, Negative tests.
3. Save each request (Ctrl/Cmd + S) into a folder with a clear name, e.g. “POST create object – 201”.

Shortcut: the API Testing Practice page has a Postman collection button that downloads a ready-made collection for this API. In Postman click Import and drop the file in.

Variables and Environments

Hardcoding https://sqatools.in/wp-json/sqa-api/v1 into 50 requests is painful when the team moves to a staging server. Use variables.

Create an environment

1. Environments → +, name it “SQA Practice”.
2. Add variable baseUrl = https://sqatools.in/wp-json/sqa-api/v1.
3. Add username = admin and password = admin@123; set the password type to secret.
4. Select the environment in the top-right dropdown.
5. Change your request URLs to {{baseUrl}}/users, {{baseUrl}}/objects…

Variable scopes (narrowest wins)

If the same name exists in several scopes, the narrower one (local, then data, then environment, then collection, then global) wins.

Authorization Tab

Set auth once at the collection level and let requests Inherit auth from parent.

Postman shows the header it generates (e.g. Authorization: Basic c3FhX3VzZXI6c3FhQDEyMw==) under the Headers tab’s hidden headers.

Request Chaining: Use Data from One Response in the Next

Real flows need values from earlier responses: a token from login, an id from create. In the Scripts → Post-response tab of the login request:

const body = pm.response.json();
pm.environment.set('access_token', body.access_token);

And in “POST create object”:

pm.collectionVariables.set('objectId', pm.response.json().id);

Then GET {{baseUrl}}/objects/{{objectId}}, PATCH {{baseUrl}}/objects/{{objectId}} and DELETE {{baseUrl}}/objects/{{objectId}} just work, in order. Run the folder with the Collection Runner and you have an end-to-end CRUD flow.

Dynamic variables

Postman has built-in random data: {{$randomFirstName}}, {{$randomEmail}}, {{$randomInt}}, {{$guid}}, {{$timestamp}}. Use them so every run creates unique data:

{ "name": "{{$randomProductName}}", "data": { "ref": "{{$guid}}" }, "ttl": 120 }

A Quick Look at Tests (Assertions)

Add checks in Scripts → Post-response:

pm.test('status is 201', () => pm.response.to.have.status(201));
pm.test('has Location header', () => pm.response.to.have.header('Location'));
pm.test('name echoed back', () => {
  pm.expect(pm.response.json().name).to.eql('Postman test object');
});

Results appear in the Test Results tab. Writing powerful scripts, schema validation, data-driven runs and Newman are covered in the next lesson: Postman Tests, Scripts and Newman.

Useful Postman Features Testers Forget

• Console (View → Show Postman Console): the exact request sent, after variables were resolved. Check here first when something “doesn’t work”.
• Code snippet (</> icon): converts a request into cURL, Python, JavaScript and more. Paste cURL into bug reports.
• Import cURL: paste a developer’s cURL command into Import to get a ready request.
• Import OpenAPI: generates a whole collection from a Swagger file.
• Settings per request: disable “Automatically follow redirects” to test 3xx codes; set request timeout.
• Mock servers: fake an API from saved examples so front-end and tests can start early.
• Postbot (AI assistant): generates test scripts and documentation from responses. Review what it writes.

Postman Practice Exercises

1. Build a collection with folders Users, Products, Objects, Auth using {{baseUrl}}.
2. GET page 2 of users with 5 per page; confirm ids 6 to 10.
3. Filter products by category=books; then try category=toys (expect 400).
4. Create an object, save its id with a script, then PATCH, GET and DELETE it in a chained run.
5. Call /basic/profile, /apikey/profile and /auth/me with each auth type; then each with wrong credentials.
6. Turn off “follow redirects” and GET /redirect: confirm 302 and the Location header.
7. Create a second environment “SQA Practice – broken” with a wrong baseUrl and see how errors look.

Interview Questions: Postman

How to Write API Test Cases: Template, Examples and 50+ Scenarios

“Write test cases for this API” is both a daily task and a favourite interview exercise. Most beginners write five happy-path cases and stop. Experienced testers use a repeatable method that produces 30 to 50 meaningful cases for a single endpoint in under an hour. In this lesson you’ll get a ready-to-use API test case template, the five test design techniques that generate cases systematically, and a complete worked example on a real endpoint you can execute right away.

Where API Test Cases Come From

Before writing a single case, collect the inputs:

• API specification (OpenAPI/Swagger, WSDL, Postman docs): endpoints, fields, types, required flags, status codes.
• Business requirements / user stories: rules like “age must be 18 to 100”, “only admins can delete”.
• Acceptance criteria and conversations with developers and product owners.
• Existing bugs and production incidents: past failures tell you where to look.

The API Test Case Template

Keep this in a spreadsheet, a test management tool (Jira Xray, Zephyr, TestRail) or directly as a Postman collection where each request is a case and its scripts are the expected results.

5 Techniques That Generate API Test Cases

1. Equivalence Partitioning (EP)

Group inputs that should behave the same and test one value per group. For role with allowed values admin/editor/viewer: valid partition {admin}, invalid partitions {unknown value “manager”}, {wrong type 5}, {empty “”}, {null}.

2. Boundary Value Analysis (BVA)

Bugs cluster at the edges. For a range min..max test min-1, min, max, max+1 (and optionally min+1, max-1).

3. Decision Tables

For rules that combine conditions. Example: delete an object on /token/objects.

4. State Transition

Resources have lifecycles. An object: does not exist → created (v1) → updated (v2, v3…) → deleted or expired. Test valid transitions and invalid ones: update after delete (404), delete twice (404), read after TTL expiry (404), update with a stale version (412).

5. Error Guessing (Experience Checklist)

Empty body, malformed JSON, wrong Content-Type, very long strings, Unicode and emojis, leading/trailing spaces, duplicate requests, special characters, SQL/HTML strings, numbers as strings, nulls, extra fields, huge numbers, negative numbers, decimals where integers expected.

Worked Example: Test Cases for POST /objects

Specification (from the practice API docs): name required, 1 to 100 characters; data any JSON up to 5 KB; ttl 10 to 1800 seconds, default 600; other fields → 422; success → 201 with Location and ETag; body over 10 KB → 413.

curl -i \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"name":"Test case demo","data":{"qty":2},"ttl":60}' \
  "https://sqatools.in/wp-json/sqa-api/v1/objects"

28 cases from one endpoint, and every one of them is concrete and runnable. The practice page has 141 more, grouped exactly like this: API Testing Practice scenarios.

The Generic Checklist for Any Endpoint

Prioritising: You Can’t Run Everything Every Time

• P1 (smoke/critical): main happy paths, auth works, money calculations. Run on every deployment.
• P2 (regression): validation, roles, state transitions. Run on every build/nightly.
• P3 (extended): rare edge cases, large data, Unicode. Run before releases.

Risk-based rule: anything touching money, personal data, permissions or irreversible actions gets higher priority.

Writing Good Test Case Titles

Format: [Method] [endpoint] [expected outcome] when/for [condition]. Strong titles become readable automated test names too.

From Test Cases to Automation

A well-written table converts directly into data-driven Playwright tests: each row becomes an object, and one loop runs them all.

import { test, expect } from '@playwright/test';

const BASE = 'https://sqatools.in/wp-json/sqa-api/v1';

const cases = [
  { id: 'TC_10', title: 'ttl 9 is rejected',    body: { name: 'A', ttl: 9 },    status: 422 },
  { id: 'TC_11', title: 'ttl 10 is accepted',   body: { name: 'A', ttl: 10 },   status: 201 },
  { id: 'TC_12', title: 'ttl 1800 is accepted', body: { name: 'A', ttl: 1800 }, status: 201 },
  { id: 'TC_13', title: 'ttl 1801 is rejected', body: { name: 'A', ttl: 1801 }, status: 422 },
  { id: 'TC_05', title: 'name is required',     body: { data: {} },             status: 422 },
  { id: 'TC_15', title: 'client id is refused', body: { id: 'x', name: 'A' },   status: 422 },
];

for (const c of cases) {
  test(`${c.id} POST /objects: ${c.title}`, async ({ request }) => {
    const res = await request.post(`${BASE}/objects`, { data: c.body });
    expect(res.status()).toBe(c.status);
  });
}

Common Mistakes in API Test Design

• Only positive cases. Aim for more negative than positive.
• “Expected: error” instead of the exact status and message.
• Not verifying side effects (was it saved? was nothing saved on failure?).
• Test cases that depend on each other’s data and order.
• Ignoring headers and response time.
• Copying the developer’s unit tests instead of thinking like a user and an attacker.

Interview Questions: API Test Cases

API Security Testing: OWASP API Top 10 Checklist with Examples

APIs now carry most of the world’s sensitive data: payments, health records, KYC documents, location history. Attackers know it, and most large data breaches of recent years trace back to an API that trusted the wrong request. You don’t need to be a penetration tester to catch these bugs. In this lesson you’ll learn the OWASP API Security Top 10 in plain language, with a real-life example and concrete test cases for each risk that any QA engineer can run.

Why QA Engineers Must Test API Security

• Security teams run penetration tests once or twice a year; QA tests every sprint.
• The most common API vulnerabilities are logic bugs (wrong ownership checks, missing limits), not exotic exploits. Testers who know the business rules find them best.
• Fixing a security bug before release costs a fraction of a breach: fines under data protection laws like India’s DPDP Act and GDPR, incident response and lost customer trust.

OWASP API Security Top 10 at a Glance

API1: Broken Object Level Authorization (BOLA)

Tests: two users of the same role; access each other’s resources via path, query and body ids; check list endpoints don’t return other users’ items; expect 403/404. Full method in Authorization Testing.

API2: Broken Authentication

Tests: no rate limit on login or OTP; tokens without expiry; tokens accepted after logout; weak password rules; different messages for wrong user vs wrong password; credentials in URLs; alg: none JWTs. The practice API rejects tampered, expired and revoked tokens, so you can see correct behaviour; the JWT lesson has all the steps.

API3: Broken Object Property Level Authorization

Two halves: excessive data exposure (the response contains fields the UI hides, like password_hash, pan_number, internal flags) and mass assignment (the client can set fields like role, price, is_verified).

Tests: inspect every response field, not just what the screen shows; validate with a JSON Schema that has additionalProperties: false; send privileged fields in POST/PUT/PATCH and confirm they’re rejected or ignored.

API4: Unrestricted Resource Consumption

Every API call costs CPU, memory, database time and sometimes money (SMS, email, AI calls). Without limits, one user can slow down everyone or run up a huge bill.

curl -i \
  "https://sqatools.in/wp-json/sqa-api/v1/rate-limit"

Press Send six times quickly. Watch X-RateLimit-Remaining count down, then the 429.

API5: Broken Function Level Authorization

Tests: call admin endpoints with a normal user token; try methods the UI never uses (DELETE, PUT); guess admin paths (/admin, /internal, /manage); check role changes take effect. On the practice API a viewer token on POST /token/objects correctly returns 403.

API6: Unrestricted Access to Sensitive Business Flows

Tests: can one account or device buy beyond the limit per user? Can the same coupon or referral be redeemed repeatedly via the API? Are there controls such as device fingerprinting, CAPTCHA at the UI, per-user quotas and anomaly detection? Discuss these flows with the business team; they know what “abuse” means for them.

API7: Server-Side Request Forgery (SSRF)

Any feature where the API fetches a URL you supply (import from URL, profile picture URL, webhook URL, PDF generation from a link) can be abused to make the server call internal systems.

Tests (in authorised test environments only): supply http://localhost/, http://127.0.0.1:8080/admin, internal IPs (10.x, 192.168.x), the cloud metadata address http://169.254.169.254/, file:///etc/passwd and redirects to them. Expected: rejected with a validation error; only allowed domains and schemes accepted.

API8: Security Misconfiguration

• Verbose errors with stack traces, SQL or file paths (send malformed input and read the 500 body).
• Missing HTTPS or HSTS; old TLS versions.
• CORS reflecting any origin with credentials.
• Default credentials on admin consoles; debug endpoints enabled (/actuator, /debug, /swagger in production when not intended).
• Unnecessary methods enabled (TRACE).
• Sensitive responses cacheable (Cache-Control missing no-store).

The practice API returns structured errors without stack traces, even for malformed JSON:

curl -i \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"name": "Asha", ' \
  "https://sqatools.in/wp-json/sqa-api/v1/validate/user"

API9: Improper Inventory Management

Companies forget APIs: /v1/ still running after /v2/ launched, a staging server with real data exposed to the internet, a debug endpoint added for one release.

Tests: compare the API documentation with what’s actually deployed; try older versions of secured endpoints; check that non-production environments don’t contain real customer data and aren’t publicly reachable; keep an up-to-date API inventory (OpenAPI files per service).

API10: Unsafe Consumption of APIs

Your API trusts data from third-party APIs (address lookup, payment gateway, partner catalogue) more than user input. Attackers compromise or imitate the third party instead.

Tests: mock the third-party API to return malicious values (script tags, SQL strings, huge payloads, redirects, timeouts) and check your API validates and handles them; verify webhook signatures; ensure calls to partners use HTTPS and certificate validation.

Injection Testing (Still Important)

Injection isn’t a separate item in the 2023 API list, but it’s still a must-test. Send these in every text field and parameter, and expect them to be stored or rejected as plain text, never executed:

The practice API’s scenario 101 stores SQL and HTML strings in an object as plain text; create one and read it back to see correct behaviour.

Tools for API Security Testing

• Postman / Playwright: your normal tools cover most BOLA, auth, validation and rate-limit tests.
• OWASP ZAP (free): automated API scans from an OpenAPI file; proxy to inspect traffic.
• Burp Suite: intercept and modify requests, Intruder for fuzzing ids and payloads.
• Schemathesis / RESTler: generate thousands of edge-case requests from OpenAPI.
• jwt.io-style decoders and jwt_tool: inspect and attack JWTs.
• Semgrep, Snyk, Dependabot: code and dependency scanning (developer side).

A Security Smoke Suite in Playwright

import { test, expect } from '@playwright/test';

const BASE = 'https://sqatools.in/wp-json/sqa-api/v1';

test('protected endpoints refuse anonymous calls', async ({ request }) => {
  for (const path of ['/basic/profile', '/apikey/profile', '/auth/me', '/token/objects']) {
    expect((await request.get(`${BASE}${path}`)).status(), path).toBe(401);
  }
});

test('responses expose only schema fields', async ({ request }) => {
  const user = (await (await request.get(`${BASE}/users/1`)).json()).data;
  expect(Object.keys(user).sort()).toEqual(
    ['active', 'age', 'city', 'created_at', 'email', 'id', 'name', 'role', 'username']);
});

test('malformed input gives a clean 4xx without internals', async ({ request }) => {
  const res = await request.post(`${BASE}/validate/user`, {
    headers: { 'Content-Type': 'application/json' }, data: '{"name": "Asha", ',
  });
  expect(res.status()).toBe(400);
  const text = await res.text();
  for (const leak of ['Stack trace', 'Exception', '.php', 'SQL', 'wp-includes']) expect(text).not.toContain(leak);
});

test('injection strings are stored as plain text', async ({ request }) => {
  const payload = `' OR '1'='1 <script>alert(1)</script>`;
  const res = await request.post(`${BASE}/objects`, { data: { name: payload, ttl: 30 } });
  expect(res.status()).toBe(201);
  expect((await res.json()).name).toBe(payload);
});

test('rate limit kicks in with Retry-After', async ({ request }) => {
  let last;
  for (let i = 0; i < 6; i++) last = await request.get(`${BASE}/rate-limit`);
  expect(last!.status()).toBe(429);
  expect(last!.headers()['retry-after']).toBeTruthy();
});

Note the rate-limit test shares a per-IP counter, so don’t run it in parallel with itself.

Interview Questions: API Security Testing

API Authorization Testing: Roles, Permissions and 401 vs 403

Authentication proves who you are; authorization decides what you can touch. Broken authorization is the number one API security risk: a delivery partner reading every customer’s address, a viewer deleting records, a user downloading someone else’s invoice just by changing a number in the URL. In this lesson you’ll learn how to design a permission matrix, test roles and ownership, and tell 401 from 403, with live admin and viewer tokens on the practice API.

Three Levels of Authorization

401 vs 403 vs 404 in Authorization

Step 1: Build a Permission Matrix

Before testing, write down who may do what. Here is the matrix for the practice API’s token-protected objects (/token/objects):

In real projects the matrix often has 5 to 10 roles (customer, seller, support agent, finance, admin, super-admin…). It becomes the single source of truth for both developers and testers, and every cell is a test case.

Step 2: Test Function-Level Authorization (Roles)

Log in as both users (practice credentials: admin/admin@123, viewer/viewer@123):

curl -i \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"username":"viewer","password":"viewer@123"}' \
  "https://sqatools.in/wp-json/sqa-api/v1/auth/login"

BASE=https://sqatools.in/wp-json/sqa-api/v1

# Viewer can read
curl -i "$BASE/token/objects" -H "Authorization: Bearer $VIEWER"            # 200

# Viewer cannot create
curl -i -X POST "$BASE/token/objects" -H "Authorization: Bearer $VIEWER" \
  -H "Content-Type: application/json" -d '{"name":"x"}'
# 403 {"error":{"code":"forbidden","message":"The viewer role can only read objects. Log in as admin to change them."}}

# Admin can create
curl -i -X POST "$BASE/token/objects" -H "Authorization: Bearer $ADMIN" \
  -H "Content-Type: application/json" -d '{"name":"admin object","ttl":120}'   # 201

Function-level test ideas

• Every write method (POST, PUT, PATCH, DELETE) with every low-privilege role.
• Admin-only endpoints (/admin/*, /reports, /users/export) with a normal user token. Look for them in Swagger docs, the web app’s JavaScript and mobile app traffic.
• “Hidden” HTTP methods: the UI only uses GET, but does DELETE work?
• Old API versions (/v1/) that may lack the checks added in /v2/.

Step 3: Test Object-Level Authorization (BOLA / IDOR)

BOLA (also known as IDOR, Insecure Direct Object Reference) is the most common serious API bug. The API checks that you are logged in but not whether this object is yours.

How to test BOLA

1. Create two users of the same role: User A and User B.
2. As B, create a resource (order, address, document). Note its id.
3. As A, try to GET, PUT, PATCH and DELETE B’s resource.
4. Expected: 403 or 404 for every call, and B’s data unchanged (verify with B’s token).
5. Repeat for nested routes (/users/{B}/orders), list endpoints with filters (/orders?user_id=B), and ids inside the body ({"order_id": B's}).

Also test predictable ids: are they sequential (1001, 1002…) or random UUIDs? UUIDs don’t fix BOLA, but sequential ids make it much easier to exploit.

Step 4: Test Property-Level Authorization (Mass Assignment)

Send fields you shouldn’t control and check the server ignores or rejects them:

PATCH /users/me
{
  "name": "Asha",
  "role": "admin",          // privilege escalation attempt
  "wallet_balance": 99999,  // money!
  "is_verified": true
}

Expected: role, wallet_balance and is_verified are rejected (422) or silently ignored; a follow-up GET proves nothing changed. On the read side, check responses don’t include fields a role shouldn’t see (salary, internal notes, other users’ emails).

The practice API rejects unknown fields: POST /validate/user with an extra field returns 422, and POST /objects with a client-chosen id returns 422.

Automating a Permission Matrix with Playwright

Turn the matrix into data, and Playwright generates one test per cell:

import { test, expect, APIRequestContext } from '@playwright/test';

const BASE = 'https://sqatools.in/wp-json/sqa-api/v1';
const USERS = { admin: 'admin@123', viewer: 'viewer@123' } as const;
type Role = keyof typeof USERS | 'anonymous';

async function tokenFor(request: APIRequestContext, role: Role) {
  if (role === 'anonymous') return {};
  const res = await request.post(`${BASE}/auth/login`, { data: { username: role, password: USERS[role] } });
  return { Authorization: `Bearer ${(await res.json()).access_token}` };
}

const matrix: { action: string; method: 'get' | 'post'; path: string; data?: object; expect: Record<Role, number> }[] = [
  { action: 'list objects',  method: 'get',  path: '/token/objects',
    expect: { anonymous: 401, viewer: 200, admin: 200 } },
  { action: 'create object', method: 'post', path: '/token/objects', data: { name: 'rbac test', ttl: 60 },
    expect: { anonymous: 401, viewer: 403, admin: 201 } },
];

for (const row of matrix) {
  for (const role of Object.keys(row.expect) as Role[]) {
    test(`${role} -> ${row.action} = ${row.expect[role]}`, async ({ request }) => {
      const headers = await tokenFor(request, role);
      const res = await request[row.method](`${BASE}${row.path}`, { headers, data: row.data });
      expect(res.status()).toBe(row.expect[role]);
    });
  }
}

test('viewer cannot delete an admin object, admin can', async ({ request }) => {
  const admin = await tokenFor(request, 'admin');
  const viewer = await tokenFor(request, 'viewer');
  const created = await (await request.post(`${BASE}/token/objects`, { headers: admin, data: { name: 'owned', ttl: 60 } })).json();

  expect((await request.delete(`${BASE}/token/objects/${created.id}`, { headers: viewer })).status()).toBe(403);
  expect((await request.get(`${BASE}/token/objects/${created.id}`, { headers: viewer })).status()).toBe(200); // still there
  expect((await request.delete(`${BASE}/token/objects/${created.id}`, { headers: admin })).status()).toBe(204);
});

Adding a new role or endpoint now means adding one line of data, not writing new tests.

Where Authorization Bugs Hide

• New endpoints added in a hurry, especially exports, bulk operations and reports.
• Mobile-only APIs nobody tests through the web UI.
• GraphQL fields and nested resolvers (each field needs its own check).
• Background jobs and webhooks that act “as the system”.
• Role changes: a user demoted from admin still has an old token with role: admin.
• Multi-tenant SaaS: company A’s admin seeing company B’s data (tenant isolation).
• File downloads: signed URLs that never expire or are guessable.

Authorization Testing Checklist

1. Permission matrix documented and agreed.
2. Every endpoint and method tested with no token (401) and each role.
3. Two users of the same role: no cross-access (BOLA) for read, update and delete.
4. Ids in path, query, body and headers all checked.
5. Privileged fields can’t be set by the client (mass assignment).
6. Responses don’t leak fields beyond the role’s permissions.
7. Role change and account deactivation take effect immediately or at next token refresh.
8. Tenant isolation for multi-company systems.

Interview Questions: Authorization Testing

JWT Token Testing: Structure, Expiry, Tampering, Refresh and Logout

JWTs (JSON Web Tokens) keep you logged in to almost every modern app, from food delivery to banking. They also cause some of the most serious API vulnerabilities: tokens that never expire, signatures that aren’t checked, and logouts that don’t really log you out. In this lesson you’ll take a real JWT apart, then test expiry, tampering, refresh rotation and logout on the live practice API, manually and with Playwright.

What Is a JWT? (The Cinema Wristband Example)

Because the server can verify the signature with its secret key, it doesn’t need to look up a session in a database on every request. That’s why JWTs are called stateless tokens.

Anatomy of a Real JWT

Log in to the practice API and you get an access_token like this (shortened):

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczpcL1wvc3FhdG9vbHMuaW5cLyIsInN1YiI6ImFkbWluIiwi...fQ._ZDcTiyS-183vQ2eAI_zeSnPgZMdX2Z3IYBrifVfyiM
<------------- header ------------->.<-------------------- payload -------------------->.<-------- signature -------->

Decoding the first two parts (Base64URL) shows:

// Header
{ "alg": "HS256", "typ": "JWT" }

// Payload (claims)
{
  "iss": "https://sqatools.in/",   // issuer
  "sub": "admin",                  // subject: the user
  "name": "Admin User",
  "role": "admin",                 // custom claim used for authorization
  "iat": 1794482821,               // issued at (Unix seconds)
  "exp": 1794483721,               // expires at: iat + 900 s
  "jti": "2hqtst3pmbas36wm"        // unique token id (used for revocation)
}

The third part is the signature: HMACSHA256(base64url(header) + "." + base64url(payload), secret). Change one character of the header or payload and the signature no longer matches.

Standard claims to check

The Token Lifecycle on the Practice API

Start by logging in here, then copy the access_token into Postman or the cURL commands below:

curl -i \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"username":"admin","password":"admin@123"}' \
  "https://sqatools.in/wp-json/sqa-api/v1/auth/login"

You can also request a shorter lifetime for expiry testing: send "expires_in": 5 in the login body (allowed range 5 to 3600 seconds; 3 returns 422).

JWT Test Cases (Complete List)

Testing Tampering Step by Step

1. Log in as viewer / viewer@123 and copy the token.
2. Split it at the dots. Base64URL-decode the middle part.
3. Change "role":"viewer" to "role":"admin", encode it again (Base64URL, no padding).
4. Rebuild header.newPayload.originalSignature and call GET /auth/me.
5. Pass if the response is 401 (“Token signature is not valid”). Critical bug if it returns 200 with role admin.

# Quick signature tamper with cURL (replace TOKEN). Changing the last 2 characters breaks the signature.
TAMPERED="${TOKEN%??}AA"
curl -i https://sqatools.in/wp-json/sqa-api/v1/auth/me -H "Authorization: Bearer $TAMPERED"
# HTTP/1.1 401 ... "Token signature is not valid (was the token changed?)."

Testing Expiry Without Waiting 15 Minutes

Real access tokens may live 15 to 60 minutes. Waiting is slow, so testers use one of these:

• A test-only short lifetime, like the practice API’s expires_in field.
• A configuration flag in the test environment that sets token lifetime to seconds.
• An already-expired token saved from a previous run (works as long as the signing key hasn’t changed).
• Unit tests on the token validator with a fake clock (developer level).

Also test clock skew: servers usually allow 30 to 60 seconds of tolerance; a token expired an hour ago must fail.

Refresh Tokens and Rotation

Short access tokens are safer, but users don’t want to log in every 15 minutes. A refresh token (long-lived, stored securely) gets new access tokens silently. With rotation, every refresh returns a new refresh token and invalidates the old one. If an attacker steals a refresh token and the real app also uses it, the reuse is detected.

Refresh tests: refresh works once; reuse returns 401; a refresh token can’t be used as an access token (and vice versa); logout and password change revoke refresh tokens; refresh tokens have their own maximum lifetime.

JWT Testing in Postman

1. Send POST /auth/login. In the Scripts → Post-response tab add:

   pm.test('login ok', () => pm.response.to.have.status(200));
   const body = pm.response.json();
   pm.environment.set('access_token', body.access_token);
   pm.environment.set('refresh_token', body.refresh_token);

2. On GET /auth/me, set Authorization → Bearer Token to {{access_token}}.
3. Duplicate the request, change the token to {{access_token}}x and assert 401.

Full Postman scripting is in Postman Tests and Newman.

JWT Tests in Playwright (TypeScript)

import { test, expect, APIRequestContext } from '@playwright/test';

const BASE = 'https://sqatools.in/wp-json/sqa-api/v1';

async function login(request: APIRequestContext, user = 'admin', pass = 'admin@123', expires_in?: number) {
  const res = await request.post(`${BASE}/auth/login`, { data: { username: user, password: pass, expires_in } });
  expect(res.status()).toBe(200);
  return res.json() as Promise<{ access_token: string; refresh_token: string; expires_in: number }>;
}
const bearer = (t: string) => ({ Authorization: `Bearer ${t}` });
const decode = (t: string) => JSON.parse(Buffer.from(t.split('.')[1], 'base64url').toString());

test('payload has expected claims and no secrets', async ({ request }) => {
  const { access_token } = await login(request);
  const claims = decode(access_token);
  expect(claims).toMatchObject({ sub: 'admin', role: 'admin', iss: 'https://sqatools.in/' });
  expect(claims.exp - claims.iat).toBe(900);
  expect(JSON.stringify(claims)).not.toContain('admin@123');
});

test('forged role in payload is rejected', async ({ request }) => {
  const { access_token } = await login(request, 'viewer', 'viewer@123');
  const [h, p, s] = access_token.split('.');
  const forged = Buffer.from(JSON.stringify({ ...decode(access_token), role: 'admin' })).toString('base64url');
  const res = await request.get(`${BASE}/auth/me`, { headers: bearer(`${h}.${forged}.${s}`) });
  expect(res.status()).toBe(401);
});

test('expired token is rejected', async ({ request }) => {
  test.setTimeout(30_000);
  const { access_token } = await login(request, 'admin', 'admin@123', 5);
  await new Promise(r => setTimeout(r, 7_000));
  expect((await request.get(`${BASE}/auth/me`, { headers: bearer(access_token) })).status()).toBe(401);
});

test('refresh token rotates and works only once', async ({ request }) => {
  const { refresh_token } = await login(request);
  expect((await request.post(`${BASE}/auth/refresh`, { data: { refresh_token } })).status()).toBe(200);
  expect((await request.post(`${BASE}/auth/refresh`, { data: { refresh_token } })).status()).toBe(401);
});

test('logout revokes the access token', async ({ request }) => {
  const { access_token } = await login(request);
  expect((await request.post(`${BASE}/auth/logout`, { headers: bearer(access_token) })).status()).toBe(204);
  expect((await request.get(`${BASE}/auth/me`, { headers: bearer(access_token) })).status()).toBe(401);
});

JWT Security Checklist

• Signature always verified; alg: none and algorithm switching (RS256 → HS256) rejected.
• Strong secret; tokens from other environments rejected.
• Short exp; expiry enforced; refresh tokens rotated.
• Logout, password change and role change take effect.
• No sensitive data in the payload.
• Authorization decisions use server data or verified claims, never values sent by the client in the body.
• Tokens stored safely on clients (HttpOnly cookies or secure mobile storage).

Interview Questions: JWT Testing

API Authentication Types: Basic Auth, API Key, Bearer Token and OAuth 2.0

Every serious API asks one question before it does anything: who are you? That is authentication. Get it wrong and anyone can read customer data; test it badly and you’ll miss the bug that leaks it. In this lesson you will learn the four authentication methods you’ll meet in real projects (Basic auth, API keys, Bearer tokens/JWT and OAuth 2.0), where each one is used in real life, and exactly which tests to run for each one on the live practice API.

Authentication vs Authorization

This lesson covers authentication. Authorization gets its own lesson: roles and 401 vs 403.

The 4 Main Authentication Types at a Glance

Others you may meet: Digest auth (older, rarely used), HMAC signatures (AWS, payment webhooks), mutual TLS (bank-to-bank APIs) and session cookies (covered in the cookies lesson).

1. Basic Authentication

The client joins username and password with a colon, encodes it in Base64 and sends it in every request:

sqa_user:sqa@123  →  Base64  →  c3FhX3VzZXI6c3FhQDEyMw==
Authorization: Basic c3FhX3VzZXI6c3FhQDEyMw==

Practice credentials (public, for this API only): sqa_user / sqa@123.

curl -i \
  -H "Authorization: Basic c3FhX3VzZXI6c3FhQDEyMw==" \
  "https://sqatools.in/wp-json/sqa-api/v1/basic/profile"

Basic auth test cases

2. API Key Authentication

An API key is a long random string issued to an application, not to a person. The server looks it up to know which client is calling, which plan it’s on and how many calls it may make.

curl -i \
  -H "X-API-Key: sqa-key-12345" \
  "https://sqatools.in/wp-json/sqa-api/v1/apikey/profile"

API key test cases

3. Bearer Token Authentication (JWT)

The user logs in once with username and password. The server returns a short-lived access token, and the client sends it as a “bearer” in every request. “Bearer” means whoever holds this token gets access, so it must be protected like a password.

1. POST /auth/login with username and password → 200 with access_token, expires_in, refresh_token.
2. GET /auth/me with Authorization: Bearer <access_token> → 200.
3. When the access token expires, POST /auth/refresh with the refresh token → new tokens without asking for the password again.
4. POST /auth/logout → the token is revoked.

curl -i \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"username":"admin","password":"admin@123"}' \
  "https://sqatools.in/wp-json/sqa-api/v1/auth/login"

The practice API’s access tokens are JWTs that last 900 seconds (15 minutes). Users: admin / admin@123 (can write) and viewer / viewer@123 (read-only). JWT internals, expiry and tampering tests are covered in depth in JWT Token Testing.

Bearer token test cases

• Valid login returns a token; wrong password returns 401; missing fields return 422.
• Protected endpoint without a token → 401; with a garbage token → 401.
• Wrong scheme (Token xyz instead of Bearer xyz) → 401.
• Expired, tampered or revoked token → 401.
• The password is never echoed back; the token never appears in URLs.

4. OAuth 2.0

OAuth 2.0 is an authorization framework: it lets a user give an application limited access to their data on another service without sharing their password.

The four roles

• Resource owner: you (the user).
• Client: the app that wants access (the printing site).
• Authorization server: issues tokens (Google’s accounts server, Okta, Keycloak, Auth0).
• Resource server: the API holding the data (Google Photos API).

Common OAuth 2.0 grant types (flows)

OpenID Connect (OIDC) adds identity on top of OAuth 2.0: an ID token (a JWT) telling the app who the user is. “Login with Google” is OIDC.

OAuth 2.0 test cases

• Token request with wrong client_secret → 401 invalid_client.
• Token with scope read calling a write endpoint → 403 insufficient_scope.
• redirect_uri not on the allowed list → rejected (prevents token theft).
• state parameter checked (prevents CSRF in the login flow).
• Authorization code can be used only once and expires quickly.
• Revoked consent stops access immediately (or at token expiry).

In Postman, the Authorization → OAuth 2.0 tab can run these flows for you and store the token; you’ll use it in the Postman tutorial.

Which Authentication Should an API Use?

Automating All Auth Types with Playwright

import { test, expect } from '@playwright/test';

const BASE = 'https://sqatools.in/wp-json/sqa-api/v1';

test('Basic auth: valid and missing credentials', async ({ request }) => {
  const basic = 'Basic ' + Buffer.from('sqa_user:sqa@123').toString('base64');
  expect((await request.get(`${BASE}/basic/profile`, { headers: { Authorization: basic } })).status()).toBe(200);

  const none = await request.get(`${BASE}/basic/profile`);
  expect(none.status()).toBe(401);
  expect(none.headers()['www-authenticate']).toContain('Basic');
});

test('API key: valid, wrong and missing', async ({ request }) => {
  const url = `${BASE}/apikey/profile`;
  expect((await request.get(url, { headers: { 'X-API-Key': 'sqa-key-12345' } })).status()).toBe(200);
  expect((await request.get(url, { headers: { 'X-API-Key': 'wrong-key' } })).status()).toBe(403);
  expect((await request.get(url)).status()).toBe(401);
});

test('Bearer token: login then call a protected endpoint', async ({ request }) => {
  const login = await request.post(`${BASE}/auth/login`, {
    data: { username: 'admin', password: 'admin@123' },
  });
  expect(login.status()).toBe(200);
  const { access_token, token_type, expires_in } = await login.json();
  expect(token_type).toBe('Bearer');
  expect(expires_in).toBe(900);

  const me = await request.get(`${BASE}/auth/me`, { headers: { Authorization: `Bearer ${access_token}` } });
  expect((await me.json()).data).toMatchObject({ username: 'admin', role: 'admin', can_write: true });
});

Playwright also supports Basic auth globally through httpCredentials in the config, and you’ll learn to share a login token across tests with fixtures in Module 6.

Common Authentication Bugs

• Different error messages for “unknown user” and “wrong password” (lets attackers find valid usernames).
• No rate limit on login (brute force), or on OTP verification.
• Tokens that never expire, or that still work after logout or password change.
• Tokens or keys in URLs, logs or error messages.
• Endpoints that someone forgot to protect (often new or “internal” ones). Call every endpoint with no credentials.
• 500 errors for malformed Authorization headers.

Authentication Testing Checklist

1. Every protected endpoint returns 401 without credentials.
2. Invalid, malformed, expired and revoked credentials return 401.
3. 401 responses include WWW-Authenticate.
4. Error messages don’t reveal whether the user exists.
5. Login and key validation are rate limited.
6. Credentials travel only over HTTPS and only in headers.
7. Secrets aren’t logged, cached or returned.
8. Logout and password change invalidate tokens.

Interview Questions: API Authentication

HTTP vs HTTPS, Cookies, Sessions and CORS for API Testers

Three topics confuse new API testers more than anything else: why HTTPS matters when “the API works fine on HTTP”, how a website remembers you are logged in (cookies, sessions or tokens), and the famous red “blocked by CORS policy” error that appears in the browser while the same call works perfectly in Postman. This lesson explains all three with everyday examples and gives you a practical test checklist for each.

HTTP vs HTTPS (The Postcard vs Sealed Envelope Example)

How HTTPS works (simplified TLS handshake)

1. The client says hello and lists the TLS versions and ciphers it supports.
2. The server replies with its certificate (containing its public key) signed by a Certificate Authority such as Let’s Encrypt or DigiCert.
3. The client checks the certificate: trusted issuer, not expired, matches the domain name.
4. Both sides agree on a shared secret session key.
5. All HTTP data is now encrypted with that key.

The request and response inside are exactly the same as HTTP; only the transport is protected. That’s why everything you learned about methods, headers and status codes applies unchanged.

How to Test HTTPS for APIs

# See the TLS handshake and certificate details
curl -v https://sqatools.in/wp-json/sqa-api/v1/health 2>&1 | grep -E "SSL connection|subject|expire|issuer"

Cookies Explained for API Testers

A cookie is a small name-value pair that the server sets with a Set-Cookie response header. The browser stores it and automatically sends it back in a Cookie request header on every later request to that site.

HTTP/1.1 200 OK
Set-Cookie: session_id=8f2a9c1e77; Path=/; Secure; HttpOnly; SameSite=Lax; Max-Age=1800

GET /account HTTP/1.1
Cookie: session_id=8f2a9c1e77

Cookie attributes you must test

Sessions vs Tokens (JWT)

The practice API supports token login with refresh and logout, which you will test in detail in the JWT lesson of Module 3:

curl -i \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"username":"admin","password":"admin@123"}' \
  "https://sqatools.in/wp-json/sqa-api/v1/auth/login"

These are public practice credentials published on the API practice page; never use real credentials on practice systems.

Session and token test cases

• After logout, the old session id or token is rejected (401).
• Session or token expires after the configured idle and absolute timeouts.
• A new session id is issued after login (prevents session fixation).
• Session ids are long and random, not sequential.
• Changing the password invalidates other sessions.
• Tokens never appear in URLs or logs.

What Is CORS? (And Why Postman Works When the Browser Fails)

Browsers follow the Same-Origin Policy: JavaScript on one origin (scheme + host + port) can’t read responses from another origin unless that server explicitly allows it. CORS is the mechanism a server uses to say “these other origins may read my responses”.

Simple vs pre-flighted requests

For “non-simple” requests (PUT, DELETE, PATCH, custom headers like Authorization, or JSON content type), the browser first sends an automatic OPTIONS pre-flight:

OPTIONS /api/cart HTTP/1.1
Origin: https://shop.com
Access-Control-Request-Method: DELETE
Access-Control-Request-Headers: authorization, content-type

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://shop.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Authorization, Content-Type
Access-Control-Max-Age: 600

Only if the pre-flight approves does the browser send the real DELETE.

CORS response headers

The SQA Tools practice API is CORS-enabled and exposes headers such as Location, ETag, Retry-After and X-Total-Count, which is why the “Send request” boxes in these lessons can show them.

CORS test cases

• Allowed origin: response contains the matching Access-Control-Allow-Origin.
• Unknown origin (e.g. https://evil.example): no allow-origin header for it.
• Security bug: the server reflects any Origin back and sends Allow-Credentials: true. Any website can then read logged-in users’ data.
• Access-Control-Allow-Origin: * combined with credentials is invalid and must not be used.
• Pre-flight OPTIONS returns 2xx with the right methods and headers.
• Headers the frontend needs (Location, ETag, pagination) are exposed.

# Simulate a browser pre-flight from another origin
curl -i -X OPTIONS "https://api.example.com/v1/cart" \
  -H "Origin: https://evil.example" \
  -H "Access-Control-Request-Method: DELETE"
# PASS if the response does NOT allow https://evil.example

Playwright: Checking Cookies, HTTPS and CORS Headers

import { test, expect } from '@playwright/test';

test('API is served only over HTTPS', async ({ request }) => {
  const res = await request.get('https://sqatools.in/wp-json/sqa-api/v1/health');
  expect(res.url()).toMatch(/^https:\/\//);
  expect(res.ok()).toBeTruthy();
});

test('session cookie has secure attributes', async ({ request }) => {
  // Replace with your application's login endpoint
  const res = await request.post('https://your-app.test/api/login', {
    data: { username: 'qa_user', password: process.env.QA_PASSWORD },
  });
  const setCookie = res.headersArray().filter(h => h.name.toLowerCase() === 'set-cookie');
  const session = setCookie.find(h => h.value.startsWith('session_id='));
  expect(session?.value).toContain('Secure');
  expect(session?.value).toContain('HttpOnly');
  expect(session?.value).toMatch(/SameSite=(Lax|Strict)/i);
});

test('CORS does not trust random origins', async ({ request }) => {
  const res = await request.fetch('https://your-app.test/api/cart', {
    method: 'OPTIONS',
    headers: { Origin: 'https://evil.example', 'Access-Control-Request-Method': 'DELETE' },
  });
  expect(res.headers()['access-control-allow-origin']).not.toBe('https://evil.example');
});

Use headersArray() for Set-Cookie because a response can contain several cookies with the same header name. Keep real passwords in environment variables, never in test code.

Common Mistakes

• Reporting a CORS error as an “API down” bug. Check the browser console and the response headers first; the API usually works in Postman.
• “Fixing” CORS with Access-Control-Allow-Origin: * on an API that uses cookies.
• Disabling certificate checks (ignoreHTTPSErrors, curl -k) in production tests.
• Storing JWTs in localStorage without considering XSS risk.
• Not testing what happens after logout or expiry.

Interview Questions: HTTPS, Cookies and CORS

JSON, XML and JSON Schema Validation for API Testers

Almost every API response you test will be JSON, and banking or SOAP systems will hand you XML. To write good assertions you must read nested data fluently, know the exact data types, and be able to prove the whole structure is correct, not just one field. In this lesson you will learn JSON and XML from a tester’s point of view, how to extract values with JSONPath and XPath, and how JSON Schema validation catches the bugs that field-by-field checks miss.

JSON Basics in 5 Minutes

Here is a real response from the practice API: GET /orders/5001.

{
  "data": {
    "id": 5001,
    "user_id": 1,
    "status": "delivered",
    "ordered_at": "2025-09-02T11:00:00Z",
    "items": [
      { "product_id": 101, "name": "Wireless Mouse", "quantity": 2, "unit_price": 799, "line_total": 1598 },
      { "product_id": 108, "name": "Python Testing eBook", "quantity": 1, "unit_price": 349, "line_total": 349 }
    ],
    "summary": { "item_count": 2, "subtotal": 1947, "tax": 350.46, "total": 2297.46, "currency": "INR" },
    "shipping": { "city": "Pune", "pincode": "411001", "country": "IN" }
  }
}

Reading Nested JSON: Paths

To assert a value you need its path. In JavaScript/TypeScript (Playwright) and in JSONPath:

Postman also uses this JavaScript syntax inside its test scripts: pm.response.json().data.status.

Assert Business Logic, Not Only Values

Good testers recompute numbers from the response itself:

• Each line_total = quantity x unit_price (2 x 799 = 1598 ✔).
• subtotal = sum of line totals (1598 + 349 = 1947 ✔).
• tax = 18% of subtotal (1947 x 0.18 = 350.46 ✔).
• total = subtotal + tax (2297.46 ✔).
• item_count = length of items (2 ✔).

curl -i \
  "https://sqatools.in/wp-json/sqa-api/v1/orders/5001"

XML Basics for API Testers

Ask the practice API for XML using the Accept header:

curl -i \
  -H "Accept: application/xml" \
  "https://sqatools.in/wp-json/sqa-api/v1/users/1"

<?xml version="1.0" encoding="UTF-8"?>
<response>
  <data>
    <id>1</id>
    <name>Asha Verma</name>
    <role>admin</role>
    <active>true</active>
  </data>
</response>

XML key concepts: elements (<name>), attributes (<price currency="INR">), namespaces (xmlns:soap="...", essential in SOAP), and every value is text until a schema (XSD) gives it a type.

XPath: extracting values from XML

SoapUI’s XPath Match assertion uses exactly these expressions; you will use them in the SoapUI lessons.

JSON vs XML

What Is JSON Schema?

A JSON Schema is a contract for JSON data. Instead of writing 30 assertions for 30 fields, you validate the whole response against one schema. The practice API publishes its schema for users:

curl -i \
  "https://sqatools.in/wp-json/sqa-api/v1/schema/user"

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "user",
  "type": "object",
  "required": ["id", "name", "username", "email", "role", "city", "age", "active", "created_at"],
  "properties": {
    "id":         { "type": "integer", "minimum": 1 },
    "name":       { "type": "string" },
    "email":      { "type": "string", "format": "email" },
    "role":       { "enum": ["admin", "editor", "viewer"] },
    "age":        { "type": "integer", "minimum": 18 },
    "active":     { "type": "boolean" },
    "created_at": { "type": "string", "format": "date-time" }
  },
  "additionalProperties": false
}

Important JSON Schema keywords

JSON Schema Validation in Playwright (with Ajv)

Install the most popular validator: npm i -D ajv ajv-formats.

import { test, expect } from '@playwright/test';
import Ajv from 'ajv';
import addFormats from 'ajv-formats';

const BASE = 'https://sqatools.in/wp-json/sqa-api/v1';
const ajv = new Ajv({ allErrors: true });
addFormats(ajv);

test('every user matches the published JSON Schema', async ({ request }) => {
  // 1. Get the contract from the API itself
  const schema = await (await request.get(`${BASE}/schema/user`)).json();
  const validate = ajv.compile(schema);

  // 2. Validate all 12 users
  const users = (await (await request.get(`${BASE}/users`, { params: { per_page: 50 } })).json()).data;
  for (const user of users) {
    const ok = validate(user);
    expect(ok, JSON.stringify(validate.errors, null, 2)).toBe(true);
  }
});

test('order totals are internally consistent', async ({ request }) => {
  const { data: order } = await (await request.get(`${BASE}/orders/5001`)).json();

  for (const item of order.items) {
    expect(item.line_total).toBe(item.quantity * item.unit_price);
  }
  const subtotal = order.items.reduce((sum: number, i: any) => sum + i.line_total, 0);
  expect(order.summary.subtotal).toBe(subtotal);
  expect(order.summary.tax).toBeCloseTo(subtotal * 0.18, 2);
  expect(order.summary.total).toBeCloseTo(subtotal + order.summary.tax, 2);
  expect(typeof order.shipping.pincode).toBe('string');
});

When validation fails, Ajv tells you exactly what broke, for example /age must be integer or must NOT have additional properties: password_hash. TypeScript teams also use Zod schemas, which double as TypeScript types; you will use both in Module 6.

JSON Testing Checklist

• Response body is valid JSON (parsing doesn’t throw), even for errors.
• Correct data types: numbers aren’t strings, booleans aren’t “true”.
• Required fields present; no unexpected or sensitive fields.
• Null vs missing vs empty string behave as documented.
• Dates in one consistent format (ISO 8601 with time zone, e.g. 2025-09-02T11:00:00Z).
• Arrays: empty list returns [], not null.
• Calculated fields are correct; money compared safely.
• Unicode (Hindi names, emojis) survives a round trip.
• Malformed JSON in a request returns 400, not 500.

Try the last check now. This request sends broken JSON (the body stops halfway), and a well-built API must answer 400 with a clear message:

curl -i \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"name": "Asha", "email": ' \
  "https://sqatools.in/wp-json/sqa-api/v1/validate/user"

Common Mistakes

• Comparing a whole response with a saved copy: timestamps and ids change, so tests flake. Validate structure with a schema and assert only the stable values.
• Using toEqual on objects when extra fields are allowed: use toMatchObject for partial matching.
• Assuming key order: JSON objects are unordered.
• Assuming array order when the API doesn’t promise one.
• Ignoring additionalProperties: that’s how data leaks go unnoticed.

Interview Questions: JSON, XML and Schema

Path Parameters vs Query Parameters, Pagination, Filtering and Sorting

Open any shopping app, search “headphones”, filter by price, sort by rating and scroll to page 3. Every one of those taps changes the parameters of an API call. Parameters are where a huge share of API bugs hide: off-by-one pagination, filters that ignore case, sorting that silently fails, and ids that let you read someone else’s data. This lesson explains path vs query parameters and gives you a complete test design for pagination, filtering, sorting and search, all runnable on the practice API.

Path vs Query Parameters (with a Library Example)

There are two more places for data: headers (metadata such as auth) and the request body (the payload for POST/PUT/PATCH). Some older APIs also use matrix parameters (;color=red), but you’ll rarely see them.

Testing Path Parameters

Path parameters look simple, but they carry some of the worst bugs, including the number one API security risk.

curl -i \
  "https://sqatools.in/wp-json/sqa-api/v1/users/0"

Pagination: Why APIs Split Data into Pages

Amazon can’t return 50 million products in one response. Pagination returns a small slice at a time. The three common styles:

The practice API has 12 users and uses page-based pagination. It returns the page details in both the body (meta, links) and headers (X-Total-Count, X-Total-Pages, Link).

curl -i \
  "https://sqatools.in/wp-json/sqa-api/v1/users?page=2&per_page=5"

Page 2 with 5 per page must start at the 6th record (id 6) and contain ids 6 to 10.

Pagination Test Cases (Boundary Value Analysis)

Filtering

Filters narrow a collection. Test each filter alone, in combination, with invalid values and with edge cases such as case sensitivity.

curl -i \
  "https://sqatools.in/wp-json/sqa-api/v1/products?min_price=5000&max_price=100"

Sorting

Why the whitelist matters: if sort is pasted directly into SQL (ORDER BY {sort}), it is an injection point. A 400 for unknown fields is the secure behaviour.

Search

• Match: /users?q=gupta returns Manish Gupta.
• No match: /users?q=zzz returns 200 with an empty list, not 404.
• Partial and case: “GUP”, “gup” behave as documented.
• Special characters: %, _, ', emojis, Hindi text (?q=%E0%A4%86%E0%A4%B6%E0%A4%BE) don’t cause 500.
• Long input: 5,000 characters is rejected cleanly.
• Search + filter + pagination together.

URL Encoding: The Silent Bug Source

Query values containing spaces or special characters must be URL-encoded: a space becomes %20 (or +), & becomes %26, @ becomes %40.

Postman and Playwright’s params option encode values for you; hand-built URL strings don’t.

Automating Parameter Tests with Playwright

import { test, expect } from '@playwright/test';

const BASE = 'https://sqatools.in/wp-json/sqa-api/v1';

test('page 2 starts at the 6th record', async ({ request }) => {
  const res = await request.get(`${BASE}/users`, { params: { page: 2, per_page: 5 } });
  const body = await res.json();
  expect(body.data.map((u: any) => u.id)).toEqual([6, 7, 8, 9, 10]);
  expect(body.meta).toMatchObject({ page: 2, per_page: 5, total: 12, total_pages: 3 });
});

test('walking all pages returns 12 unique users', async ({ request }) => {
  const ids: number[] = [];
  for (let page = 1; ; page++) {
    const body = await (await request.get(`${BASE}/users`, { params: { page, per_page: 5 } })).json();
    if (body.data.length === 0) break;
    ids.push(...body.data.map((u: any) => u.id));
  }
  expect(ids).toHaveLength(12);
  expect(new Set(ids).size).toBe(12);   // no duplicates
});

test('every filtered user is an admin', async ({ request }) => {
  const body = await (await request.get(`${BASE}/users`, { params: { role: 'admin', per_page: 50 } })).json();
  expect(body.data.length).toBeGreaterThan(0);
  for (const u of body.data) expect(u.role).toBe('admin');
});

test('sorted by age descending', async ({ request }) => {
  const body = await (await request.get(`${BASE}/users`, { params: { sort: 'age', order: 'desc', per_page: 50 } })).json();
  const ages = body.data.map((u: any) => u.age);
  expect(ages).toEqual([...ages].sort((a, b) => b - a));
});

for (const bad of ['per_page=51', 'page=0', 'active=maybe', 'sort=salary', 'order=up']) {
  test(`invalid query ${bad} -> 400`, async ({ request }) => {
    expect((await request.get(`${BASE}/users?${bad}`)).status()).toBe(400);
  });
}

Interview Questions: Parameters and Pagination