Security Testing Basics

Why this matters

As an API Engineer, you are a gatekeeper for data and business processes. Basic security testing helps you prevent data leaks, fraud, downtime, and trust damage. Real tasks you will face:

• Verify that endpoints enforce authentication and authorization correctly.
• Check that inputs are validated and cannot trigger injection or server-side request forgery.
• Ensure rate limiting, pagination, and error handling do not leak sensitive data.
• Confirm tokens, sessions, and TLS are configured securely.
• Review logs and configs for secrets and personal data exposure.

Concept explained simply

Security testing checks whether your API refuses dangerous requests and permits only what is intended. Think of it as rattling every door and window of a house to confirm the locks and alarms are working.

Mental model

Use the AAA flow: Authenticate → Authorize → Accept input. For every endpoint, ask three questions:

• Who are you? (Authentication)
• Are you allowed? (Authorization)
• Is your request safe? (Input, rate, and context checks)

What to look for first: a quick checklist

• Authentication: Endpoints require valid tokens or keys; no guest shortcuts.
• Authorization: You cannot access or modify resources you do not own (no IDOR).
• Input validation: Reject unexpected fields, types, and sizes; deny file/URL inputs unless explicitly required.
• Rate limiting: Rapid repeated requests yield 429/blocked responses.
• Error handling: Errors are generic; stack traces and secrets are not exposed.
• Cryptography: TLS enforced; tokens have reasonable expiry; JWTs are signed and verified.
• Data exposure: Responses and logs don’t include secrets or PII unless necessary and masked.
• CORS: Only trusted origins allowed; not set to wildcard for credentialed requests.

Worked examples

Example 1: Authorization gap (IDOR)

API: GET /v1/accounts/1234

1. Authenticate as user A who owns account 1234.
2. Change path to /v1/accounts/1235.
3. Expected: 403 or 404; Actual risk: 200 with someone else’s data.

Example 2: JWT weakness

Check: Token expiry and signature verification.

1. Decode JWT header and payload locally (no secret needed to decode).
2. Look for exp/cl exp claims; is expiry far in the future?
3. Attempt to use a token after expiry or with modified payload.

Example 3: Rate limiting

Endpoint: POST /v1/login

1. Send increasing login attempts for the same account with wrong passwords.
2. Expected: lockout or 429 after a small threshold; response times may increase.
3. If unlimited attempts succeed with stable latency, brute force may be possible.

Hands-on exercises

These mirror the exercises at the bottom of the page so you can practice directly here.

{
  "GET /v1/books": "List books (public list, no auth)",
  "POST /v1/books": "Create book (auth required)",
  "GET /v1/books/{id}": "Get book details (public)",
  "PATCH /v1/books/{id}": "Update book (owner or admin)",
  "DELETE /v1/books/{id}": "Delete book (admin)",
  "POST /v1/upload-cover": "Upload image by URL (auth required)"
}

{
  "userId": "u-123",
  "items": [{"sku": "SKU-1", "qty": 2}],
  "delivery": {"type": "home", "address": "..."}
}

Exercise checklist

• Your test cases state both the test input and the expected safe response.
• At least one test covers each: auth, authorization, input validation, rate limiting, errors/logging.
• You considered denial-of-service angles (payload size, request burst).

Common mistakes and self-check

• Confusing authentication with authorization: Self-check by attempting to access another user’s resource with a valid token.
• Only testing happy paths: Add at least three negative tests per endpoint.
• Ignoring error messages: Ensure errors are generic; no stack traces, secrets, or SQL errors.
• Skipping rate limits: Simulate bursts and verify 429 or backoff mechanisms.
• Trusting client-side validation: Send malformed inputs directly to the API.

Practical projects

• Harden a demo API: Add auth to write endpoints, implement 429 rate limits, and mask sensitive fields in responses and logs.
• Threat-based test plan: Pick 3 high-risk endpoints and write a 1-page plan covering IDOR, input validation, and rate limits, then execute it.
• Token review: Evaluate token lifetimes, scopes, and revocation; propose safer defaults and test them.

Learning path

1. Map the API surface: list endpoints, auth methods, and data sensitivity.
2. Run AAA checks per endpoint (auth, authorization, input acceptance).
3. Add negative tests for common API risks: IDOR, injection, SSRF, rate limiting.
4. Automate critical checks as integration tests and run them on every change.

Who this is for

• API Engineers and Backend Developers adding security tests to their workflow.
• QA Engineers transitioning into API security basics.
• DevOps/SRE ensuring safer production behavior under load and errors.

Prerequisites

• Comfort with HTTP methods, status codes, and JSON.
• Basic understanding of authentication (tokens, API keys) and authorization concepts.
• Ability to read simple API specifications.

Next steps

• Turn your manual checks into automated tests in your CI.
• Expand coverage to cover input boundaries and abuse cases.
• Review logs and monitoring to catch security anomalies early.

Mini challenge

Pick one public read endpoint and one write endpoint in a demo or test API. For each, write three negative tests: one auth, one authorization, and one input validation. Define the expected safe responses.

Ready to check yourself?

The quick test below is available to everyone. Only logged-in users will have their progress saved.