API Security and Testing Questions

Comprehensive coverage of testing and securing application programming interfaces. Includes designing, implementing, and automating tests across functional, integration, regression, and security areas. Core topics include authentication and authorization models and how to validate them in tests; request and response validation and schema enforcement; data format testing for JavaScript Object Notation and Extensible Markup Language; contract testing and integration validation; rate limiting and denial of service protections; input validation and injection attack detection; sensitive data exposure detection and prevention; business logic flaw analysis; fuzz testing; and penetration testing integration. Also covers test automation strategies and tooling such as Postman, Newman, and REST-assured; mocking and stubbing downstream services; testing complex behaviors across microservice architectures; test environment and test data management; and integrating automated API tests into continuous integration and continuous delivery pipelines. Emphasizes automated security testing workflows including reconnaissance, authentication and authorization checks, injection attack simulation, data exfiltration checks, and incorporation of API security into penetration testing and remediation processes. Finally, addresses monitoring, observability, runtime protections such as API gateways and web application firewalls, and best practices for secure API design, testing, and ongoing validation.

EasyTechnical

54 practiced

You are a Test Automation Engineer for a REST API secured with JSON Web Tokens (JWT). Describe an automated test plan that validates authentication and authorization across the following cases: valid token access, expired token handling, refresh token flow, token tampering or signature invalidation, scope and role checks, and token revocation or blacklisting. Specify what assertions you would automate, which endpoints to hit, how to generate or mock tokens safely, and how to run these checks in CI pipelines.

Sample Answer

**Plan summary**Design a suite of isolated API tests that exercise auth flows end-to-end and via token manipulation. Automate as part of the CI pipeline with pytest + requests (or your team stack) and use test accounts + a token-minting test client.

**Test cases & endpoints**- Valid token access - Endpoint: GET /api/resource - Setup: obtain JWT by POST /auth/login with test user - Assertions: 200 OK, expected payload, response.headers contains cache/auth info- Expired token - Setup: mint token with short exp or alter exp claim to past - Hit GET /api/resource - Assertions: 401 Unauthorized, error code/message "token_expired"- Refresh token flow - Endpoint: POST /auth/refresh - Setup: use valid refresh token from login - Assertions: 200 OK, new access_token with later exp, old refresh still valid/rotated according to policy- Token tampering/signature invalidation - Setup: flip a byte in signature or replace alg to none - Assertions: 401 Unauthorized, error "invalid_signature"- Scope/role checks - Endpoints: POST /api/admin-only, GET /api/user-profile - Setup: tokens with/without scopes/roles - Assertions: 403 Forbidden for insufficient scope, 200 for correct role- Token revocation/blacklisting - Setup: revoke token via POST /auth/revoke or add to blacklist - Assertions: subsequent call returns 401/403 as policy dictates

**How to generate/mock tokens safely**- Prefer a test-only token-issuing endpoint or use JWT libraries to sign tokens with test private key (keep test keys in CI secrets)- For tampering tests, build token then mutate header/payload/signature strings- Do not use real user credentials in VCS; store test creds and private keys in CI secrets or Vault

**Automation specifics**- Implement tests in pytest with fixtures: - fixture: test_user_login() -> returns access_token, refresh_token - fixture: mint_token(claim_overrides) -> build token signed with test key- Example (Python) token mint:

python

import jwt, time
def mint_token(claims, secret):
    claims.setdefault("exp", int(time.time()) + 60)
    return jwt.encode(claims, secret, algorithm="HS256")

- Assertions: status code, JSON error code, token exp comparisons, response body authorization fields- Run as fast unit/integration tests; mark longer end-to-end auth-only tests separately

**CI integration**- Add stage "auth-tests" in pipeline after deploy-to-test- Inject secrets via CI secret manager- Fail pipeline on assertion failures; archive request/response logs for debugging- Run revoked/rotation tests in isolated environment to avoid flakiness (reset blacklist between runs)

**Observability & maintenance**- Log token values (masked) and request IDs on failure- Parameterize tests for different algorithms (HS256/RS256) and environments- Keep test keys and minting logic in test utilities repository, reviewed by security team

This plan verifies correct auth behavior, covers edge cases, and is safe for CI usage.

MediumTechnical

53 practiced

Design a fuzz testing approach for a set of REST APIs that includes both stateless endpoints and stateful flows across microservices. Describe tools and strategies you would use, how you would derive inputs from OpenAPI specs, how you would maintain state between calls, and how you would determine an oracle to detect real failures versus expected errors.

Sample Answer

**Approach overview**I’d build a hybrid fuzzing pipeline: schema-driven input generation for stateless endpoints + guided, stateful scenario fuzzer that composes calls across services. Integrate into CI to run quick passes and nightly deep fuzz runs.

**Tools & stack**- OpenAPI-based generators: Schemathesis or Dredd for spec-driven fuzzing- Custom harness in Python (requests + hypothesis) or Go for performance- Service virtualization: WireMock / Mountebank to stub external deps- Observability: Jaeger, Prometheus, ELK for traces/logs- CI: GitLab/GitHub Actions to run and report

**Deriving inputs from OpenAPI**- Parse OpenAPI to extract paths, methods, parameter schemas, auth flows.- Use Schemathesis/Hypothesis to generate valid/invalid payloads respecting types, formats, enums, and constraints; add mutation strategies (boundary, large payloads, SQL/JSON injection).

**Maintaining state between calls**- Model flows as state machines: define sequences (e.g., create -> update -> delete). Maintain context object carrying IDs, tokens, etags.- Use scenario generators that replay sequences with mutated intermediate payloads.- For microservices, either run against a test environment with isolated DB snapshots or use containerized ephemeral environments per run; persist state in test harness, seed DB or use API to create fixtures.

**Oracle & failure classification**- Multi-layer oracles: - Contract-level: HTTP 5xx or schema-violating responses flagged as failures. - Business-level: check invariants (e.g., item created appears in list, balances conserved). - Observability signals: unexpected errors in logs/traces within request window.- Use expected-error whitelist from OpenAPI (declared responses) and negative-test expectations; correlate traces + logs to reduce false positives.- Triage: automatically reduce failing sequence via delta-debugging to minimal reproducer and tag as true failure if reproducer yields 5xx or invariant breach.

**Metrics & integration**- Track coverage (endpoints, schema branches), failure rate, unique crash signatures, time-to-reproduce.- Fail CI on regressions; create bug reports with reproducible sequence, payload, and trace links.

This approach balances broad spec-driven fuzzing with targeted stateful scenarios and strong oracles to focus on real defects.

MediumTechnical

49 practiced

Provide a set of automated test ideas and concrete test cases that would help detect business logic flaws in an e commerce API. Examples to consider include discount stacking, price manipulation via client-side fields, skipping payment for specific sequences, and privilege escalation to alter order status. Explain how you would automate and prioritize these tests.

Sample Answer

**Approach / Framework**- Use risk-based, stateful API tests focused on core money/auth flows. Automate at API level (pytest + requests or Postman/Newman), with DB and message-queue assertions, running in CI on PRs and nightly regression.

**Concrete test ideas & cases**- Discount stacking - Case: apply coupon A (10%) + coupon B (15%) => verify business rule (only one coupon or max discount). Assert final price matches allowed rule and audit log recorded.- Client-side price manipulation - Case: submit order JSON with modified line-item unit_price lower than catalog price. Assert server recalculates price from canonical product service; reject or correct client price.- Skipping payment sequence - Case: attempt to create order -> set status = "paid" via API without calling payment gateway. Assert server requires payment token and verifies payment provider webhook before marking paid.- Privilege escalation on order status - Case: user token attempts to set order.status -> "shipped" or "refunded". Assert 403 for non-staff and verify role-based server-side checks.- Race / idempotency / replay - Case: replay same payment webhook twice; assert idempotent handling and no double-capture.- Inventory and negative stock - Case: simultaneous checkout requests for last item; assert inventory decrement and one order fails.

**How to automate**- Implement reusable fixtures: test users (roles), product catalog, payment stubs (sandbox Webhook emulator), DB snapshots.- Use contract tests for product/pricing service to prevent trusting client values.- Implement stateful scenarios as test flows with checkpoints: API responses, DB row assertions, messages on queue.- Add property-based tests/mutations for price fields and auth tokens.

**Prioritization**1. Payment integrity (skip-payment, replay) — highest risk2. Pricing/auth correctness (client price manipulation, discount stacking)3. Privilege checks (status changes)4. Concurrency/inventory- Run high-risk tests on every PR; full suite nightly.

**Metrics & CI**- Fail-fast tests for money flows, collect flaky-test metrics, record HTTP logs and DB diffs on failure, auto-create bug tickets for sovereignty rule violations.

MediumSystem Design

46 practiced

Design a CI integration for OWASP ZAP or Burp to run automated DAST scans against authenticated API endpoints as part of a pipeline. Explain how you would authenticate sessions for the scanner, scope the scans to safe targets, set severity thresholds for pipeline failure, and manage false positives and remediation workflow.

Sample Answer

**Overview / goal**Design CI steps to run authenticated DAST (OWASP ZAP or Burp) against API endpoints so scans run safely in pipeline, fail build on meaningful risk, and feed a manageable remediation workflow.

**Architecture**- CI job (Jenkins/GitHub Actions/GitLab CI) runs a container image with ZAP CLI or Burp Scanner + API client.- Pre-scan: deploy/test environment (ephemeral), seed test data, and start an auth mock if needed.- Scan: authenticated scan against API base path only.- Post-scan: parse reports (JSON/HTML), apply thresholds, create tickets, and store artifacts.

**Authentication / session handling**- Prefer token-based auth to avoid brittle UI flows: - Use short-lived API tokens (CI secrets) or OAuth client credentials obtained via CI step. - For session cookies (if required), use ZAP’s scripted authentication or Burp’s session handling to perform login requests then persist session cookie for subsequent requests.- Store secrets in CI secret vault, rotate regularly. Use service accounts with least privilege and environment-scoped credentials.

**Scoping & safe targeting**- Define scanning context (ZAP Context or Burp Target Scope): - Limit to API base domain and paths (/api/v1/*). Blocklist dangerous endpoints: /payments/charge, /email/send, destructive admin endpoints. - Use rate limits, throttle scan (concurrency, delays) and set safe HTTP methods (GET/HEAD by default); only enable POST/PUT with explicit allowlists and test data. - Use a CI flag to toggle “deeper” scans (nightly) vs quick scans (PRs).

**Severity thresholds & pipeline gating**- Map tool severities to gating policy. Example: - Fail pipeline if High >= 1 OR Medium >= 5. - Warn (continue) if Medium 1–4 or Low > 0.- Implement baseline comparisons: ignore issues already in baseline unless severity increases.- Expose flag to allow override for emergency merges with audit log.

**False positives & remediation workflow**- Post-process results with rule-based suppression: known false-positive signatures, authenticated-only noise, or endpoints behind proxy.- Integrate with ticketing: auto-create triage tickets with scan summary, evidence, and suggested remediation steps; attach raw report and curl samples for reproductions.- Assign to responsible team via ownership mapping (path -> service owner).- Provide “mark as false positive” via an issues file (.dast-suppression.yml) stored in repo or in scanner’s exclude rules; changes require PR so suppressions are reviewed.- Maintain a feedback loop: after developer fixes, run verification quick-scan (targeted endpoints) and auto-close tickets when resolved.

**Operational considerations**- Keep scans fast for PRs: use quick passive + shallow active scans. Full active/full crawl reserved for nightly.- Store artifacts (SARIF/JSON/HTML) in CI for audits and for automated triage tools.- Logging and alerts for auth failures, rate limits, or scanner errors to avoid silent gaps.

This design balances safety, speed, and actionable findings—enabling CI-integrated DAST that scales with the team while keeping false positives and noise manageable.

MediumTechnical

54 practiced

Implement or outline a REST-assured Java test that performs a full OAuth2 token refresh scenario: obtain initial access and refresh tokens, simulate or wait for access token expiry, use the refresh token to get a new access token, then assert that the new token works and that token reuse or replay of the same refresh token is handled per expected policy. Describe any test environment requirements to make this deterministic.

Sample Answer

**Approach (brief)**1. Get initial tokens from /oauth/token (password or client_credentials).2. Force expiry (use short TTL in test env or call an admin endpoint to expire).3. POST refresh_token grant to get new access token.4. Assert new token works, and test refresh-token reuse/replay behavior per policy (single-use vs multi-use).

**Sample Rest-Assured Java test**

java

import io.restassured.RestAssured;
import io.restassured.response.Response;
import static org.hamcrest.MatcherAssert.assertThat;
import static org.hamcrest.Matchers.*;

@Test
public void refreshTokenFlow() {
  // 1. Obtain initial tokens
  Response initial = RestAssured.given()
    .auth().preemptive().basic("client","secret")
    .formParam("grant_type","password")
    .formParam("username","testuser")
    .formParam("password","pass")
    .post("/oauth/token");
  String access1 = initial.jsonPath().getString("access_token");
  String refresh = initial.jsonPath().getString("refresh_token");
  assertThat(access1, notNullValue());
  assertThat(refresh, notNullValue());

  // 2. Make token expired deterministically (test-only admin endpoint)
  RestAssured.given().auth().basic("admin","admin")
    .post("/test/expire-token?access=" + access1);

  // 3. Use refresh token
  Response refreshed = RestAssured.given()
    .auth().preemptive().basic("client","secret")
    .formParam("grant_type","refresh_token")
    .formParam("refresh_token", refresh)
    .post("/oauth/token");
  String access2 = refreshed.jsonPath().getString("access_token");
  assertThat(access2, notNullValue());
  assertThat(access2, not(equalTo(access1)));

  // 4. Verify new token works
  RestAssured.given().auth().oauth2(access2)
    .get("/api/protected")
    .then().statusCode(200);

  // 5. Verify refresh token reuse policy (single-use -> second attempt fails)
  RestAssured.given()
    .auth().preemptive().basic("client","secret")
    .formParam("grant_type","refresh_token")
    .formParam("refresh_token", refresh)
    .post("/oauth/token")
    .then().statusCode(anyOf(equalTo(400), equalTo(401)));
}

**Why / Deterministic test env**- Use configurable short TTLs for tokens or a test-only admin endpoint to expire tokens instantly.- Isolate test tenant and test client to avoid concurrency/replay flakiness.- Seed test users and revoke state between runs.- Mock external auth servers if third-party dependencies are unstable.

**Assertions to include**- New access token differs and is usable.- Refresh reuse behavior matches policy (assert expected error code/body).- Token revocation propagated (attempt using old access token yields 401).

Unlock Full Question Bank

Get access to hundreds of API Security and Testing interview questions and detailed answers.

Join thousands of developers preparing for their dream job.