When most people picture web testing, they imagine someone clicking through a web page, filling out forms, and seeing if a button works. But modern web development isn't happening on the surface anymore. The real application lives beneath the UI—in a web of REST, GraphQL, and microservice APIs connecting databases, cloud functions, and third-party services.
When a bug manifests on a webpage, it’s usually just a symptom. The root cause almost always lives deep down in an API response or a security oversight.
Let’s step past basic functional checks and take a deep, practical dive into the most elusive, critical bugs found in API and Security Testing—how they happen, how to find them, and how to report them like a seasoned QA engineer.
Part 1: Anatomy of an API Bug
API bugs are inherently quiet. They don't throw colorful browser alerts or misalign CSS buttons. They operate in raw HTTP response payloads, headers, and status codes.
Here are the three most critical categories of API bugs found in modern applications:
1. The Masked Error: Status Code Mismatches
One of the most common API design flaws is returning an HTTP 200 OK status code when the action actually failed.
* The Scenario: A client app sends a POST request to update a user profile with invalid data.
* The Response:
HTTP/1.1 200 OK
{
"status": "error",
"code": 4001,
"message": "Invalid email format supplied."
}
* Why it's a Bug: Frontends and downstream integration services rely on HTTP status codes (4xx/5xx) to handle errors automatically. Masking a failure behind a 200 OK causes silent failures, breaks monitoring tools (like DataDog or New Relic), and forces frontend engineers to parse custom response payloads for every single API call.
2. Schema Drift & Contract Violations
In a microservices architecture, Team A might manage the backend API, while Team B builds the web frontend. If Team A changes an data type in the API response—say, converting user_id from an integer (1042) to a string ("usr_1042")—without updating the schema contract:
* Frontend components fail silently or render undefined.
* Downstream mobile and web builds crash due to type mismatches during parsing.
* How to catch it: Contract testing frameworks (like Pact or Schemathesis) compare the live API payload against the official OpenAPI/Swagger specification on every pull request.
3. Business Logic & State Sequence Breaks
Automated tests often execute requests sequentially: Step A → Step B → Step C. But malicious actors or race conditions don't follow scripts.
* The Scenario: An e-commerce API requires three steps: POST /cart/checkout, POST /payment/charge, and POST /order/confirm.
* The Bug: What happens if you skip step 2 and fire POST /order/confirm directly with an active session token?
* If the API fails to validate state transitions server-side, it creates an order without ever charging the credit card.
Part 2: Security Vulnerabilities (The OWASP API Deep Dive)
Security testing is no longer just about running an automated scanner at the end of a sprint. It’s about understanding how API design flaws allow attackers to manipulate data.
1. BOLA (Broken Object Level Authorization)
Ranked as the #1 threat on the OWASP API Security Top 10, BOLA occurs when an API endpoint accepts an object identifier from the user without verifying if that user actually owns the object.
How It Happens:
Suppose you view your account invoices on a website. Your browser sends this API request:
GET /api/v1/invoices/98421 HTTP/1.1
Host: application.com
Authorization: Bearer <your_valid_token>
You receive your invoice details. But what happens if you change the numerical ID in the request path?
GET /api/v1/invoices/98422 HTTP/1.1
If the backend validates that your token is active, but fails to check whether user 98422 belongs to your account ID, it returns another user's invoice.
> Testing Tip: Always test APIs using two distinct user accounts (User A and User B). Swap resource IDs between their requests while keeping their respective authentication tokens.
>
2. Mass Assignment (Data Injection)
Modern web frameworks allow developers to automatically bind incoming request parameters directly to database models. While convenient, it opens a dangerous door if input parameters aren't strictly sanitized.
The Scenario:
When registering a user account, the frontend sends this payload:
POST /api/v1/users
{
"username": "johndoe",
"email": "john@example.com",
"password": "SecurePassword123!"
}
An analyst testing for Mass Assignment adds an administrative field that isn't present in the UI form:
POST /api/v1/users
{
"username": "johndoe",
"email": "john@example.com",
"password": "SecurePassword123!",
"is_admin": true,
"role": "administrator"
}
If the API blindly maps incoming JSON keys to the database user model without using an explicit allowlist (DTO), johndoe is instantly created as a system administrator.
3. Rate Limiting & Volumetric Abuse
Without proper rate limiting, endpoints like password reset requests, login verification, or credit card processing become prime targets for automated attacks.
* The Bug: Sending 500 requests in 10 seconds to POST /api/v1/auth/forgot-password.
* Impact: Causes email server queuing delays, high SMS gateway charges, or potential brute-force account lockouts across your entire user base.
* What to check: Verify that the API returns 429 Too Many Requests with a clear Retry-After header once threshold limits are breached.
Part 3: How to Write an Unbeatable API Bug Report
Finding a subtle API or security bug is only half the battle. If your bug report is vague or lacks context, developers will lose time trying to reproduce it or push back with "cannot reproduce."
A great API bug report reads like a precise diagnostic report. Here is a battle-tested template:
Bug Report Example: BOLA Vulnerability on Invoice Endpoint
Title: [Security][BOLA] User can access arbitrary invoices by mutating the invoice ID in GET /api/v1/invoices/{id}
Severity: Critical | Priority: High
Environment: Staging (v2.14.0-rc1)
1. Executive Summary
The GET /api/v1/invoices/{id} endpoint validates user authentication tokens but fails to enforce authorization checks against the resource owner. An authenticated user can view financial details, address information, and payment histories of any other user by iterating through invoice IDs.
2. Prerequisites
* Two valid user accounts:
* User A (Victim): account_id: 101, Invoice ID: 8801
* User B (Attacker): account_id: 102, Token: eyJhbGciOi...
3. Steps to Reproduce
* Log in as User B and capture the JWT authentication token.
* Issue a GET request to /api/v1/invoices/8801 using User B's token.
* Observe the server response.
4. Raw HTTP Request
GET /api/v1/invoices/8801 HTTP/1.1
Host: staging-api.app.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
User-Agent: PostmanRuntime/7.32.3
Accept: application/json
5. Actual Result
The API returns a 200 OK status with User A's private invoice details:
HTTP/1.1 200 OK
Content-Type: application/json
{
"invoice_id": 8801,
"owner_email": "userA@example.com",
"billing_address": "123 Main St, San Francisco, CA",
"total_amount": 1450.00,
"status": "PAID"
}
6. Expected Result
The API should verify that invoice 8801 belongs to account_id matching User B's token, and return a 403 Forbidden status code:
HTTP/1.1 403 Forbidden
Content-Type: application/json
{
"error": "Forbidden",
"message": "You do not have permission to access this resource."
}
7. Business Impact & Remediation Guidance
* Impact: Potential data breach and compliance violation (GDPR/PCI-DSS) due to unauthorized exposure of Personal Identifiable Information (PII).
* Suggested Fix: Implement server-side record ownership checks inside the controller or middleware layer before database retrieval:
WHERE invoice_id = :id AND user_id = :current_user_id
Final Thoughts
Testing at the API and security layer requires shifting your mindset from "Does this feature work?" to "How can this service be misused or abused?"
When you learn to inspect status codes, analyze raw JSON payloads, break sequencing, and test boundary conditions, you transition from someone who simply tests software to someone who truly secures and stabilizes the engineering architecture.
What type of API or security bug do you encounter most often in your projects? Let me know in the comments below!
Comments
Post a Comment