API security · authentication · authorization · input validation · CORS · OWASP · indie developers

API Security Basics Every Small Team Needs to Get Right

A practical guide to authentication, authorization, input validation, and CORS for indie developers building APIs without a security team.

Published: August 2, 2026

Why API Security Matters for Small Teams

If you are building APIs as an indie developer or a small software team, you might assume that security is something reserved for large organizations with dedicated security teams. That assumption is wrong. APIs are increasingly targeted by attackers precisely because smaller teams often ship functionality before hardening. The OWASP API Security Project exists to address this gap, noting that “many APIs do not undergo the rigorous security testing that would help make them secure from an attack” [1].

This article covers the essential security measures every small API should implement: authentication, authorization, encryption in transit, input validation, and avoiding common pitfalls like over-permissive CORS. No fluff, no invented benchmarks—just the trade-offs you need to understand.

Authentication vs. Authorization: Two Different Problems

These two terms are often used interchangeably, but they solve different problems. Authentication answers the question: “Who are you?” Authorization answers: “What are you allowed to do?”

Authentication

Authentication is the process of verifying the identity of the caller. For APIs, this typically means issuing and validating tokens. The OWASP API Security Top 10 lists “Broken Authentication” as API2:2023, warning that “authentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws to assume other users’ identities” [3].

Practical steps for small teams:

• Use established token formats. JWTs are widely supported but require careful handling. Never trust claims without validation. Use short-lived access tokens paired with refresh tokens for longer sessions.
• Never store secrets in client-side code. API keys embedded in JavaScript running in the browser are visible to anyone who inspects the source.
• Enforce secure contexts. The browser restricts many powerful APIs to secure contexts—those delivered over TLS [7]. This is not optional if your API handles any sensitive data. A man-in-the-middle attacker on an unencrypted connection can intercept tokens, credentials, and user data.

Authorization

Authorization controls what an authenticated user can access. The most common failure mode for small teams is broken object-level authorization. OWASP API1:2023 describes this as APIs exposing endpoints that handle object identifiers without checking whether the caller owns or is authorized to access that specific object [3].

Consider an endpoint like GET /api/orders/12345. If your code simply looks up order 12345 by the ID in the URL and returns it, any authenticated user can enumerate and access any order. The fix is straightforward: after authenticating the user, verify that the order belongs to them before returning it.

Similarly, OWASP API5:2023 highlights broken function-level authorization, where complex access control policies with different hierarchies and roles lead to flaws that let attackers access administrative functions [3]. If you have admin endpoints, gate them behind explicit role checks, not just authentication.

Encryption in Transit Is Non-Negotiable

Sending API data over unencrypted HTTP is one of the simplest and most dangerous mistakes a small team can make. The MDN Secure Contexts documentation explains that secure contexts exist to “prevent MITM attackers from accessing powerful APIs that could further compromise the victim” [7]. This principle applies equally to your API server.

Requirements:

• Use TLS 1.2 or higher. TLS 1.3 is preferred. Older versions have known vulnerabilities.
• Obtain valid certificates. Self-signed certificates work for development but will cause failures in production and with most API consumers. Use Let’s Encrypt or a trusted certificate authority.
• Honor the secure context requirement. Many browser APIs and features are restricted to secure contexts [8]. If your frontend calls your API over HTTP, those features will simply not work, and your tokens will be exposed.

Input Validation: Your First Line of Defense

Input validation means checking that data received by your API conforms to what you expect. Without it, attackers can inject malicious payloads, overflow buffers, or manipulate your application logic.

Key principles:

• Validate on the server, not just the client. Client-side validation is convenient for user experience but trivial to bypass. Every API endpoint must validate its own inputs.
• Use allowlists, not denylists. Rejecting known-bad patterns is fragile. Accepting only the shapes and ranges you expect is far more robust.
• Check types, lengths, and formats. A user ID that should be an integer should not accept a string. An email field should validate the format before it reaches your database.
• Be careful with deserialization. Parsing untrusted JSON, XML, or other serialized formats without validation is a well-known attack vector. OWASP API7:2023 covers Server-Side Request Forgery, which occurs “when an API is fetching a remote resource without validating the user-supplied URI” [3]. If your API accepts a URL and fetches from it, validate that URL against an allowlist of permitted domains.

CORS Security Risks

Cross-Origin Resource Sharing (CORS) is a browser mechanism that controls whether a web page from one origin can request resources from another. It is often misconfigured, and misconfiguration is one of the most common API security issues.

Common mistakes:

• Using Access-Control-Allow-Origin: *. This header tells the browser that any origin can access your API. If your API requires authentication, this effectively exposes your data to any malicious website. The attacker’s page can make requests to your API on behalf of an authenticated user who happens to have a session open.
• Echoing the request origin back. Some developers dynamically set Access-Control-Allow-Origin to match the Origin header from the request. This is slightly better than * but still risky if you accept any origin. Validate the origin against an explicit allowlist instead.
• Confusing CORS with authorization. CORS is a browser enforcement mechanism, not a security control. Even if CORS blocks a request in the browser, the request still reaches your server. Your server must enforce authentication and authorization independently.

Practical guidance:

1. Define an explicit allowlist of origins that should access your API.
2. Set Access-Control-Allow-Origin to one of those origins, never to * for authenticated endpoints.
3. Only expose the headers and methods your API actually needs.
4. Remember that CORS does not protect your API from direct HTTP clients like curl or Postman. Server-side checks are still required.

Operational Security for Small Teams

Security is not only about code. MDN’s Operational Security guide emphasizes that supply chain attacks target the processes you follow to develop and ship software [9]. For small teams, this means:

• Require strong authentication for project maintainers. Use passkeys or multi-factor authentication on your version control and deployment accounts. Compromised maintainer accounts are a direct path to injecting malicious code.
• Implement role-based access control. Not every team member needs write access to production. Limit privileges to what each person actually needs.
• Evaluate the tools you use. Third-party tools in your development pipeline—CI/CD systems, package registries, hosting providers—are part of your attack surface. Choose tools from reputable providers and keep them updated.

Common Pitfalls to Avoid

1. Assuming your API is too small to target. Attackers use automated scanners that probe millions of endpoints. Size does not protect you.
2. Hardcoding secrets. API keys, database passwords, and signing secrets should never appear in your source code. Use environment variables or a secrets manager.
3. Ignoring error messages. Detailed error responses can leak information about your internal structure, database schema, or stack trace. Return generic error messages to clients and log details server-side.
4. Skipping rate limiting. OWASP API4:2023 covers unrestricted resource consumption, which can lead to denial of service or increased operational costs when attackers abuse your API [3]. Rate limiting is a simple defense that prevents both accidental overload and intentional abuse.
5. Leaving debug endpoints enabled in production. OWASP API8:2023 addresses security misconfiguration, noting that complex configurations are easy to get wrong [3]. Audit your production configuration regularly and disable anything you do not actively use.

FAQ

Do I need a security team to secure my API? No. The measures described here—authentication, authorization checks, TLS, input validation, and proper CORS configuration—are foundational and can be implemented by a small team with focused effort.

How do I know if my API is vulnerable? Start by reviewing your endpoints against the OWASP API Security Top 10 [3]. Then test with tools like OWASP ZAP or Burp Suite Community Edition. Consider automated API security testing tools that integrate into your CI pipeline.

Is JWT the right choice for authentication? JWTs are convenient but require careful implementation. The key trade-off is that JWTs are self-contained, which means revoking a compromised token is harder than with session-based authentication. For small teams, consider whether a simpler session-based approach with server-side token storage might be easier to manage securely.

What about API versioning and security? Each API version should be treated as a separate deployment with its own security configuration. Do not assume that security measures from v1 automatically apply to v2.

Sources

[1] https://owasp.org/API-Security/editions/2019/en/0x03-introduction [2] https://owasp.org/www-project-api-security [3] https://owasp.org/API-Security/editions/2023/en/0x11-t10 [4] https://owasp.org/www-community/api_security_tools [5] https://owasp.org/API-Security [6] https://developer.mozilla.org/en-US/docs/Web/Security/Defenses/User_activation [7] https://developer.mozilla.org/en-US/docs/Web/Security/Defenses/Secure_Contexts [8] https://developer.mozilla.org/en-US/docs/Web/Security/Defenses/Secure_Contexts/features_restricted_to_secure_contexts [9] https://developer.mozilla.org/en-US/docs/Web/Security/Defenses/Operational_security [10] https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage