How to Secure API Endpoints: The OWASP API Top 10 With Practical Fixes

What it is: The API accepts a user-supplied resource identifier (object ID) and returns the resource without verifying that the requesting user is authorized to access that specific object.

Vulnerable pattern:

# Flask example: BOLA vulnerability
@app.route('/api/orders/<order_id>')
def get_order(order_id):
    order = db.query('SELECT * FROM orders WHERE id = ?', order_id)
    return jsonify(order)  # No check: does this user own this order?

An attacker who knows their own order ID (say, 10042) simply increments: 10043, 10044, 10045... Each responds with a different customer's order data.

The fix:

@app.route('/api/orders/<order_id>')
@login_required
def get_order(order_id):
    # Always scope the query to the authenticated user
    order = db.query(
        'SELECT * FROM orders WHERE id = ? AND user_id = ?',
        order_id, current_user.id  # Add user ownership check
    )
    if not order:
        abort(404)  # Return 404 (not 403) to avoid confirming object existence
    return jsonify(order)

The rule: Every database query that fetches a user-specific resource must include the authenticated user's ID in the WHERE clause. Authorization is not a layer on top of data retrieval: it is part of data retrieval.

API2: Broken Authentication

APIs commonly implement authentication incorrectly: accepting expired or invalid JWTs, not validating JWT signatures, allowing login without rate limiting (enabling brute force), or sending tokens in URL parameters (which end up in server logs).

JWT validation: the full checklist:

import jwt

def verify_token(token):
    try:
        payload = jwt.decode(
            token,
            SECRET_KEY,
            algorithms=['HS256'],  # Specify explicitly: never accept 'none'
            options={
                'require': ['exp', 'iss', 'sub'],  # Require expiry, issuer, subject
                'verify_exp': True,  # Verify not expired
            }
        )
        if payload['iss'] != 'https://api.yourcompany.com':  # Verify issuer
            raise ValueError('Invalid issuer')
        return payload
    except jwt.ExpiredSignatureError:
        abort(401)
    except jwt.InvalidTokenError:
        abort(401)

Never accept the alg: none header: it bypasses signature verification entirely. Always specify the accepted algorithm list explicitly.

API3: Broken Object Property Level Authorization (Mass Assignment)

APIs that bind request body directly to database objects allow attackers to set properties they should not be able to set.

Vulnerable pattern:

# Express.js: mass assignment vulnerability
app.put('/api/users/:id', (req, res) => {
    User.findByIdAndUpdate(req.params.id, req.body)  // blindly applies all request fields
})
// An attacker sends: {"name": "Alice", "role": "admin", "plan": "enterprise"}

The fix:

# Allowlist only the properties the endpoint is permitted to update
const UPDATABLE_FIELDS = ['name', 'email', 'phone']

app.put('/api/users/:id', requireAuth, (req, res) => {
    const allowedUpdates = {}
    UPDATABLE_FIELDS.forEach(field => {
        if (req.body[field] !== undefined) allowedUpdates[field] = req.body[field]
    })
    User.findByIdAndUpdate(req.params.id, allowedUpdates)
})

What it is: APIs without rate limiting allow attackers to send unlimited requests, enabling credential brute force, enumeration attacks, scraping, and denial of service.

The fix: three layers of rate limiting:

Layer 1: Per-IP rate limiting at the API gateway or reverse proxy:

# Nginx rate limiting
limit_req_zone $binary_remote_addr zone=api:10m rate=60r/m;

server {
    location /api/ {
        limit_req zone=api burst=20 nodelay;
        limit_req_status 429;
    }
}

Layer 2: Per-user/per-account rate limiting in application code:

from flask_limiter import Limiter
from flask_limiter.util import get_remote_address

limiter = Limiter(app, key_func=get_remote_address)

@app.route('/api/login', methods=['POST'])
@limiter.limit('5 per minute; 20 per hour')  # 5 login attempts per minute, 20 per hour
def login():
    ...

@app.route('/api/data')
@limiter.limit('100 per minute')  # Per-IP for data endpoints
def get_data():
    ...

Layer 3: Response headers for client transparency:

# Add rate limit headers to every response
response.headers['X-RateLimit-Limit'] = '100'
response.headers['X-RateLimit-Remaining'] = str(remaining_requests)
response.headers['X-RateLimit-Reset'] = str(reset_timestamp)

Authentication endpoints require stricter limits than data endpoints. A POST to /api/login should be limited to 5-10 attempts per minute from a single IP, with a 15-minute backoff after 10 failures. Data endpoints can be more permissive (100-200/minute) if requests are authenticated.

API5: Broken Function-Level Authorization

APIs that expose admin functions without verifying the requesting user has admin permissions: often by checking role at the route level but missing it on specific endpoints.

Vulnerable pattern:

@app.route('/api/admin/users', methods=['GET'])
@login_required  # Only checks: is user logged in
def list_all_users():
    return jsonify(db.query('SELECT * FROM users'))  # Returns all users, no role check

The fix:

@app.route('/api/admin/users', methods=['GET'])
@require_role('admin')  # Role-specific decorator, not just login_required
def list_all_users():
    return jsonify(db.query('SELECT * FROM users'))

The systematic fix: audit every API endpoint against your permission matrix. Every endpoint that performs an administrative function should have a role requirement, and that role requirement should be enforced by a decorator or middleware: not inline code that could be accidentally omitted.

API6: Unrestricted Access to Sensitive Business Flows

APIs that implement business logic (checkout, promo code redemption, account creation) without rate limiting or anomaly detection allow automation of actions that should be rate-constrained.

Examples:

• Gift card balance check endpoint with no rate limit → attackers enumerate gift card codes
• Promo code redemption with no per-account limit → attackers apply the same promo code to many accounts
• Account creation with no CAPTCHA or rate limit → attackers create thousands of accounts for credential stuffing

The fix requires business-logic-aware rate limiting:

@app.route('/api/promo-code/apply', methods=['POST'])
@login_required
@limiter.limit('3 per day', key_func=lambda: current_user.id)  # Per-USER limit, not per-IP
def apply_promo_code():
    ...

Per-IP limits do not protect against distributed abuse from many IPs. Business logic endpoints need per-account limits, transaction velocity checks, and anomaly detection for automated patterns.

A consolidated checklist for API security review:

Authentication:

• All API endpoints require authentication (except explicitly public endpoints)
• JWTs validate signature, expiry, issuer, and subject
• Authentication endpoints rate-limited to 5-10 attempts/minute per IP
• API keys are not transmitted in URL query parameters (use Authorization header)
• No secrets committed to source code (see the GitHub secrets guide)

Authorization:

• Every resource query includes the authenticated user's ID in the WHERE clause
• Admin endpoints use role-specific decorators, not just login_required
• Mass assignment prevented by field allowlisting in all update endpoints
• Indirect object references (user-supplied IDs) are validated against the authenticated user

Input validation and output filtering:

• All user input is validated: type, format, length, and range
• API responses do not include fields the caller is not authorized to see
• Error messages do not leak stack traces, database queries, or internal paths
• HTTP methods are restricted per endpoint (GET for reads, POST/PUT for writes)

Rate limiting and monitoring:

• All endpoints rate-limited (authentication endpoints: strict; data endpoints: moderate)
• Rate limit headers returned on all responses
• 429 responses logged and alerted on high volumes
• API inventory maintained: every endpoint documented with its authentication requirement