API Security Basics:Authentication, Rate Limiting and Validation

API security comes down to answering two questions correctly on every request: who is calling (authentication) and are they allowed to do this to this specific object (authorisation). Around that core, a secure API validates all input, limits request rates, returns errors that do not leak internals, keeps secrets out of code, verifies webhooks, and logs enough to investigate problems. The OWASP API Security Top 10 lists the most common failures, and broken object-level authorisation is consistently at the top.

1. Authentication

• Use established mechanisms: session cookies for first-party web apps, OAuth 2.0 / OpenID Connect for third-party access, signed tokens or API keys for server-to-server calls.
• Send credentials only over HTTPS.
• Make tokens short-lived and revocable; store refresh tokens securely.
• Never put API keys in front-end JavaScript, mobile apps or public repositories, where anyone can extract them. Keep them on the server.

2. Authorisation at the object level

Checking that a user is logged in is not enough. For every request that touches a resource, check that this user may access this record:

GET /api/orders/1043

If the API only checks "is logged in", any user can change the number and read other people's orders. This flaw (often called IDOR or BOLA) is one of the most common serious API vulnerabilities. Enforce ownership in queries (for example, look up the order within the current customer's orders) and use policies consistently.

Also check function-level permissions: ordinary users must not reach admin endpoints, even if they guess the URL.

3. Validate all input

• Validate type, length, format and allowed values for every field.
• Reject unexpected fields rather than silently accepting them; this prevents mass assignment, where a user sets a field like is_admin.
• Use parameterised queries or an ORM to prevent SQL injection.
• Limit request body sizes and upload types.

4. Return only what is needed

Do not send full database records and rely on the front end to hide fields. Build explicit responses with only the fields the caller should see, to avoid exposing internal data, other users' details or hidden flags.

5. Rate limiting and abuse protection

• Limit requests per user, token and IP address, with stricter limits on login, password reset and expensive endpoints.
• Return 429 Too Many Requests with a retry hint.
• Paginate list endpoints and cap page sizes.

6. Safe error handling

• Return consistent, generic error messages to clients.
• Never expose stack traces, SQL errors or file paths in production responses.
• Log full details on the server instead.

7. Secrets management

• Store keys and passwords in environment configuration or a secrets manager, not in code.
• Rotate secrets periodically and immediately after staff changes or suspected leaks.
• Give each integration its own key with the minimum permissions.

8. Webhooks

When other services call your API (payment confirmations, for example):

• verify the signature or shared secret on every webhook;
• reject old or replayed messages (check timestamps and IDs);
• for critical events like payments, confirm the status with the provider's API before acting.

9. CORS, deliberately

CORS settings control which websites' JavaScript may call your API from a browser. Allow only the origins you need, and never combine a wildcard origin with credentials. CORS is not an authentication mechanism.

10. Logging and monitoring

Log authentication events, authorisation failures and unusual patterns, without logging passwords, tokens or full payment details. Alert on spikes in failures.

Example: a Laravel route with object-level authorisation

A customer-facing endpoint that returns one order:

// routes/api.php
Route::middleware(['auth:sanctum', 'throttle:60,1'])
    ->get('/orders/{order}', [OrderController::class, 'show']);

// OrderController
public function show(Request $request, Order $order)
{
    $this->authorize('view', $order);           // OrderPolicy checks ownership

    return new OrderResource($order);           // returns only whitelisted fields
}

// OrderPolicy
public function view(User $user, Order $order): bool
{
    return $order->customer_id === $user->customer_id;
}

Authentication confirms who is calling, the throttle limits request rates, the policy enforces that the order belongs to the caller, and the resource class controls exactly which fields leave the server. Each piece addresses one of the risks above. See the Laravel security checklist for the wider application.

Testing authorisation automatically

Write tests that try to break the rules:

• user A requests user B's order → expect 403 or 404;
• an unauthenticated request → expect 401;
• a normal user calls an admin endpoint → expect 403;
• a request with extra fields (is_admin=true) → the field is ignored or rejected.

Running these on every change catches regressions before they reach production.

Frequently Asked Questions

Are API keys enough for security?

For simple server-to-server use, keys can be adequate if kept secret, scoped and rotated. For user data, combine authentication with proper authorisation checks.

Should internal APIs be secured the same way?

Yes. Internal APIs are often reached once an attacker gets a foothold, so they need authentication and authorisation too.

How do I test API security?

Include authorisation tests in your automated test suite (for example, "user A cannot read user B's order"), and consider professional testing for important APIs.

Related reading

See what is an API, OWASP Top 10 explained and the Laravel security checklist. For APIs designed and built securely, see ServerNeed custom web development.

API security is one part of the wider picture in website security basics.

Sources

• OWASP API Security Top 10
• OWASP REST Security Cheat Sheet

Featured image: “lock data privacy” by stockcatalog, licensed under CC BY 2.0.