25 Advanced API Security Interview Questions for 5+ Yrs Exp Developers

BOLA (Broken Object Level Authorization), also known as IDOR (Insecure Direct Object References), is the most common API vulnerability. It occurs when an API endpoint allows an attacker to access or modify a resource by simply changing the ID in the request, without properly checking if the authenticated user is authorized to access that specific resource.

Prevention: For every single request that accesses a resource by its ID, you must implement a check to verify that the currently authenticated user has ownership or permission to access that specific resource ID. Never trust the ID provided by the client alone.

BFLA occurs when an API fails to properly enforce authorization checks for different user roles or groups. For example, a regular user might discover an administrative endpoint like `POST /api/v1/admin/users` and be able to successfully call it because the endpoint itself lacks a proper authorization check to ensure the caller has an `admin` role.

Prevention: Implement a robust authorization layer, often in middleware or decorators, that checks the user’s roles and permissions before allowing access to any sensitive business function or administrative endpoint. Deny by default.

Mass Assignment is a vulnerability that occurs when a client can provide data that gets automatically bound to an internal object or data model, allowing them to overwrite sensitive, unintended fields. For example, a user might submit a JSON payload `{“email”: “[email protected]”, “isAdmin”: true}` to an update profile endpoint. If the server blindly binds the entire payload to a user object, it might unintentionally promote the user to an administrator.

Mitigation: Avoid binding incoming data directly to internal models. Instead, use Data Transfer Objects (DTOs) that only contain the specific fields you expect and allow to be modified. Maintain a strict allow-list of mutable properties.

Injection flaws (like SQLi, NoSQLi, Command Injection) occur when untrusted user input is concatenated directly into a query or command.

Prevention:

• Use Parameterized Queries: For SQL, always use prepared statements or ORMs that parameterize inputs. Never use string formatting or concatenation to build queries.
• Sanitize Input: For OS command injection, strictly validate input against an allow-list of characters and use built-in functions that do not invoke a shell.
• Use Safe APIs: Avoid dangerous functions like `eval()` in any language.

This vulnerability occurs when an API returns more data in its response than the client application actually needs or should have access to. Developers often rely on the client-side to filter this data, but an attacker can inspect the raw API response to find sensitive information (e.g., a user object that contains a hashed password or other PII).

Prevention: Implement a transformation layer (like DTOs or GraphQL schemas) on the backend that explicitly defines and exposes only the necessary fields for each API endpoint.

A common strategy is the **token bucket** or **leaky bucket** algorithm, implemented at the API Gateway or in middleware. For each client (identified by IP, API key, or user ID), you maintain a “bucket” of tokens that replenishes at a fixed rate.

Each API call consumes one token. If the bucket is empty, the request is rejected with a `429 Too Many Requests` status code. This prevents any single client from overwhelming the system with requests. You can also implement different tiers of rate limits for authenticated vs. unauthenticated users.

• `Content-Security-Policy` (CSP): A powerful header that helps prevent Cross-Site Scripting (XSS). It tells the browser which sources of content (scripts, styles, images) are trusted and allowed to be loaded, effectively creating an allow-list and blocking untrusted assets.
• `Strict-Transport-Security` (HSTS): A header that tells the browser it should only ever communicate with the site using HTTPS, never HTTP. The browser will automatically upgrade any future HTTP requests to HTTPS, preventing protocol downgrade attacks and cookie hijacking.

CORS is a browser security mechanism that controls whether a web page running on one origin (domain) is allowed to make requests to an API on a different origin. By default, browsers block these cross-origin requests for security reasons (the Same-Origin Policy).

It’s a security mechanism because it prevents malicious websites from making unauthorized requests to your API from a user’s browser. The API server must explicitly opt-in by sending back CORS headers (like `Access-Control-Allow-Origin`) to tell the browser which origins are permitted to access it.

Securing a file upload endpoint involves multiple layers:

1. Authentication/Authorization: Ensure only authenticated and authorized users can upload files.
2. Input Validation: Check the file type (using MIME type, not just the extension), enforce size limits, and scan for malware.
3. Secure Storage: Do not store uploaded files in the same directory as the application code. Use a separate, non-executable directory or, preferably, a dedicated object storage service like S3 or Azure Blob Storage.
4. Safe Serving: Serve user-uploaded content from a different domain than your main application to prevent cookie-based XSS attacks.

An API Gateway acts as a single entry point for all API requests. It’s a reverse proxy that sits in front of your backend services and provides a centralized place to handle cross-cutting concerns, such as:

• Request routing to the appropriate microservice.
• Authentication and authorization.
• Rate limiting and throttling.
• Caching and response transformation.
• Logging and monitoring.

GraphQL’s flexibility introduces unique security challenges not found in traditional REST APIs:

• Complex Query Attacks: Attackers can send deeply nested or resource-intensive queries that can overload the server, leading to a Denial of Service. This is mitigated with query depth limiting and cost analysis.
• Introspection Queries: By default, GraphQL allows clients to query the entire schema. This can be abused by attackers for reconnaissance. This should often be disabled in production.
• Granular Authorization: Authorization needs to be applied at a more granular, per-field level, which is more complex than simply securing an entire REST endpoint.
• Vague Error Messages: Default error messages can sometimes leak information about the underlying schema.

Securing a WebSocket involves several steps:

1. Use WSS: Always use the `wss://` protocol, which is WebSockets over a secure TLS connection.
2. Authentication: Since WebSockets don’t use standard HTTP headers after the initial handshake, authentication is handled differently. A common method is to have the client provide an auth token (like a JWT) as a query parameter during the initial handshake connection. The server validates this token before upgrading the connection.
3. Origin Validation: The server should validate the `Origin` header during the handshake to prevent connections from untrusted domains.
4. Input Validation: All messages received over the WebSocket must be rigorously validated, just like any other user input.

Certificate Pinning is a security mechanism where a client application is configured to only trust a specific server certificate or public key, rather than any certificate signed by a trusted Certificate Authority (CA). Pros:

• It protects against Man-in-the-Middle (MITM) attacks that rely on a compromised CA or a rogue certificate being installed on the user’s device.

• It is very brittle. If the server’s certificate expires or needs to be rotated, you must release a new version of your client application with the new pinned certificate. If you don’t, all existing clients will be unable to connect.

• A Forward Proxy sits in front of a group of client machines. It acts on behalf of the clients and is used by an organization to control and filter its users’ outbound internet traffic.
• A Reverse Proxy sits in front of a group of web servers. It acts on behalf of the servers, intercepting requests from the internet and forwarding them to the appropriate backend server. API Gateways and Load Balancers are types of reverse proxies.

You should log:

• Authentication events (successful and failed logins).
• Authorization failures (access denied events).
• High-risk events like password changes or permission changes.
• Input validation failures.
• Key details like the source IP, user agent, timestamp, and user ID for each event.

You must AVOID logging:

• Any form of raw credentials (passwords, API keys, session tokens, JWTs).
• Personally Identifiable Information (PII) like social security numbers, credit card numbers, or health information, unless absolutely necessary and properly secured with access controls.

A credential stuffing attack involves attackers using lists of stolen usernames and passwords to attempt logins. Detection involves monitoring and alerting on specific patterns:

• A high rate of failed login attempts from a single IP address or a range of IPs.
• A high ratio of failed logins to successful logins across the entire system.
• Logins for many different user accounts originating from the same IP address in a short period.

Tools like a WAF, rate limiting, and anomaly detection in your logging system are key to identifying and blocking these attacks.

A WAF is a security layer that sits between your users and your API. It inspects HTTP traffic and can block malicious requests based on a set of rules. It’s designed to protect against common web application attacks like SQL injection, Cross-Site Scripting (XSS), and path traversal. Services like AWS WAF or Cloudflare provide managed WAF capabilities.

The main risk is **Improper Assets Management**. Teams often focus on securing the latest version (`/api/v2`) but forget about older, deprecated versions (`/api/v1`) that are still running to support legacy clients. These older versions often don’t receive the same security patches and updates, making them a prime target for attackers who can exploit known vulnerabilities. It’s crucial to have a clear plan for deprecating and eventually shutting down old API versions.

“Deny by default” is a security posture where access is denied unless it has been explicitly granted. In the context of API security, this means that your authorization system should block any request that doesn’t match a specific “allow” rule. This is much safer than an “allow by default” model where you only specify what to block, as you could easily miss a new endpoint or role that needs protection.