API Security OWASP API Top 10 Checklist

By Kokil Thapa | Last reviewed: August 2026

Shipping a public or partner-facing API without a structured security review is a liability, especially when handling payments, legal documents, or personal data. The API Security OWASP API Top 10 Checklist provides the definitive framework for identifying and mitigating the most critical vulnerabilities in modern REST and GraphQL endpoints. In my experience building legal-tech portals and eCommerce systems in Nepal, applying this checklist during development—not as an afterthought—prevents costly breaches and compliance failures.

What Is the API Security OWASP API Top 10 Checklist and Why Does It Matter?

The OWASP API Security Top 10 (2023 edition, current through 2026) differs fundamentally from the traditional web application Top 10 because APIs expose structured data and business logic directly to clients, often bypassing browser-based protections. While traditional web security focuses heavily on XSS and CSRF, API security centers on authorization flaws, excessive data exposure, and automated abuse. For developers building Laravel APIs, this distinction is critical: your routes are your attack surface, and every endpoint must be treated as potentially hostile.

In practice, I have found that three categories account for over 80% of real-world API incidents in production systems I maintain: Broken Object Level Authorization (API1), Broken Authentication (API2), and Unrestricted Resource Consumption (API4). These are not theoretical; they manifest as users accessing other customers' invoices, tokens that never expire, and bots scraping entire databases through paginated endpoints. The checklist forces you to address these systematically rather than relying on ad-hoc fixes after a penetration test.

For teams in Nepal working with limited security budgets, this checklist also serves as a communication tool with clients. When building platforms like legal-tech portals that handle sensitive case files, demonstrating compliance with OWASP standards builds trust more effectively than vague assurances about "security." It transforms security from an abstract concern into a verifiable engineering deliverable.

How Do You Prevent Broken Object Level Authorization (BOLA) in Laravel APIs?

BOLA (API1) is consistently the #1 vulnerability because it exploits a fundamental assumption: that authenticated users only access their own resources. In reality, if your controller fetches a record by ID without verifying ownership, any authenticated user can enumerate and access all records. This is especially dangerous in multi-tenant systems, legal portals, and eCommerce order APIs where data isolation is non-negotiable.

Use Policies and Route Model Binding Together

Laravel’s authorization policies combined with implicit route model binding provide the most reliable defense against BOLA. Never trust client-supplied IDs without server-side verification. Here is the pattern I use on every resource endpoint:

<?php
// app/Policies/DocumentPolicy.php
namespace App\Policies;

use App\Models\Document;
use App\Models\User;

class DocumentPolicy
{
    public function view(User $user, Document $document): bool
    {
        // Strict ownership check - no exceptions
        return $document->user_id === $user->id 
            || $user->hasRole('admin');
    }
    
    public function update(User $user, Document $document): bool
    {
        return $document->user_id === $user->id;
    }
}

<?php
// app/Http/Controllers/Api/DocumentController.php
public function show(Document $document): JsonResource
{
    // Policy automatically invoked via model binding
    $this->authorize('view', $document);
    
    return new DocumentResource($document);
}

// In routes/api.php - implicit binding enforces policy
Route::apiResource('documents', DocumentController::class)
    ->middleware(['auth:sanctum']);

A common mistake is checking authorization inside the controller method but forgetting to apply it to related resources. If a document has attachments, each attachment endpoint must independently verify the parent document’s ownership. Chained authorization checks prevent horizontal privilege escalation through nested relationships.

Avoid Direct Database Queries Without Context

Raw queries bypass Laravel’s authorization layer entirely. When building reporting or search endpoints, always scope queries to the authenticated user’s context:

• Use global scopes for tenant isolation when appropriate
• Never expose primary keys in URLs if sequential enumeration is a risk; use UUIDs or hashed identifiers
• Log authorization failures separately from general errors for security monitoring
• Test BOLA explicitly in your test suite with assertions that verify User A cannot access User B’s resources

How Should You Handle Authentication and Token Management Securely?

Broken Authentication (API2) encompasses weak token generation, missing expiration, insufficient entropy, and improper session handling. For Laravel APIs in 2026, Sanctum remains the standard for SPAs and mobile apps, while Passport serves OAuth2 server requirements. Both require explicit configuration to avoid default insecure states.

Configure Token Lifetimes and Scopes Explicitly

Default Sanctum tokens never expire unless configured. This violates OWASP API2 guidelines. Set reasonable expiration based on your application’s risk profile:

// config/sanctum.php
'expiration' => 60 * 24, // 24 hours for mobile apps
// For high-security legal portals: 60 * 2 (2 hours)

// When issuing tokens with scopes
$token = $user->createToken(
    'mobile-app',
    ['documents:read', 'documents:write'],
    now()->addHours(2)
)->plainTextToken;

Scopes limit damage from compromised tokens. A token stolen from a mobile device should not grant admin privileges or access to unrelated subsystems. Define granular scopes matching your API’s functional boundaries, and validate them in middleware or policy checks.

Secure Token Storage and Transmission

Tokens transmitted over HTTP or stored in localStorage are vulnerable to interception and XSS. For SPAs, use Sanctum’s cookie-based authentication with SameSite=Strict and Secure flags. For mobile and third-party integrations, transmit tokens only over HTTPS and store them in secure platform keystores, never in plaintext preferences or logs.

I have encountered production systems where API keys were logged in plaintext during debugging, then exposed through log aggregation services. Configure your logging to redact Authorization headers and token parameters. Laravel’s $exceptions->dontReport() and custom log formatters help prevent accidental credential leakage.

How Do You Implement Effective Rate Limiting and Prevent Resource Exhaustion?

Unrestricted Resource Consumption (API4) enables denial-of-service attacks, brute-force attempts, and cost amplification through unbounded queries. Every public API endpoint must enforce rate limits proportional to business value and infrastructure capacity. Laravel’s throttle middleware provides the foundation, but effective protection requires layered configuration.

Configure Tiered Rate Limits

Apply different limits based on authentication state, endpoint sensitivity, and user tier. Anonymous endpoints need aggressive limits; authenticated endpoints can be more permissive but still bounded:

// routes/api.php
use Illuminate\Cache\RateLimiting\Limit;
use Illuminate\Support\Facades\RateLimiter;

// In RouteServiceProvider or bootstrap/app.php
RateLimiter::for('api', function (Request $request) {
    return $request->user()
        ? Limit::perMinute(120)->by($request->user()->id)
        : Limit::perMinute(20)->by($request->ip());
});

RateLimiter::for('auth-sensitive', function (Request $request) {
    return Limit::perMinute(5)->by($request->ip());
});

// Apply to routes
Route::post('/login', [AuthController::class, 'login'])
    ->middleware('throttle:auth-sensitive');

Route::apiResource('/documents', DocumentController::class)
    ->middleware(['auth:sanctum', 'throttle:api']);

Protect Against Expensive Operations

Rate limiting alone does not prevent single requests that consume disproportionate resources. Paginate all list endpoints with maximum page size enforcement. Set query timeouts for complex aggregations. Validate file upload sizes and processing complexity before accepting payloads. On a recent eCommerce project, we prevented catalog scraping by combining rate limits with pagination caps and response-time monitoring that triggered temporary blocks for slow-query patterns.

How Do You Validate Input and Prevent Mass Assignment Vulnerabilities?

Broken Object Property Level Authorization (API3) and Mass Assignment (related to API6) occur when APIs accept fields users should not modify. Laravel’s Form Requests and explicit allowlists are your primary defenses. Never pass $request->all() directly to model creation or updates.

Use Dedicated Form Requests with Explicit Rules

Define separate request classes for create and update operations. Specify exactly which fields are permitted and validate types, lengths, and formats:

<?php
// app/Http/Requests/Api/UpdateProfileRequest.php
class UpdateProfileRequest extends FormRequest
{
    public function rules(): array
    {
        return [
            'name' => ['required', 'string', 'max:255'],
            'phone' => ['nullable', 'string', 'regex:/^9[78][0-9]{8}$/'],
            // email, role, is_admin intentionally excluded
        ];
    }
    
    public function validated($key = null, $default = null): array
    {
        // Only returns fields defined in rules()
        return parent::validated($key, $default);
    }
}

// Controller receives only safe fields
public function update(UpdateProfileRequest $request): JsonResource
{
    $request->user()->update($request->validated());
    return new UserResource($request->user());
}

This pattern prevents mass assignment even if the model’s $fillable array is misconfigured. Defense in depth matters: validate at the request level AND restrict at the model level. For APIs accepting nested objects or arrays, validate each nested structure explicitly. Laravel’s array.* validation syntax handles this, but test edge cases where attackers send unexpected nesting depths or type confusion payloads.

Sanitize Output to Prevent Excessive Data Exposure

API6 (Unrestricted Access to Sensitive Business Flows) and API3 overlap when responses include fields clients should not see. Use API Resources to transform models before serialization. Never return Eloquent models directly from controllers. Define explicit field lists in resources and conditionally include sensitive attributes based on authorization context.

How Do You Audit and Maintain API Security Continuously?

Security is not a one-time checklist completion; it requires ongoing verification as code changes. Integrate automated scanning into your CI pipeline using tools like ZAP API Scan or OWASP crAPI against staging environments. Complement automation with manual testing focused on business logic flaws that scanners miss—authorization bypasses through parameter manipulation, race conditions in concurrent operations, and workflow violations.

Maintain a living security document alongside your API documentation. Map each endpoint to its corresponding OWASP controls, note known limitations, and track remediation status. When onboarding new developers or handing off projects to clients in Nepal or internationally, this documentation transfers security context that code comments cannot convey. Review it quarterly and after any significant feature release.

Monitor production for anomalies: sudden spikes in 401/403 responses indicate probing; unusual payload sizes suggest injection attempts; geographic anomalies may signal credential compromise. Laravel’s logging combined with external monitoring services provides visibility without excessive overhead. For server-level security, ensure your infrastructure complements application-layer controls with WAF rules, TLS enforcement, and network segmentation.

Implementing the API Security OWASP API Top 10 Checklist in Production

The API Security OWASP API Top 10 Checklist becomes actionable when embedded in your development workflow rather than treated as a compliance exercise. Start by auditing existing endpoints against BOLA and authentication controls—the highest-impact items. Then systematically address rate limiting, input validation, and data exposure. For new projects, make the checklist part of your definition of done for every API feature.

If you are building or auditing an API and need hands-on implementation support, reach out to discuss your specific requirements. Whether you are securing a legal portal, eCommerce platform, or SaaS product, practical security guidance grounded in real production experience beats generic advice every time.