The Cybersecurity Expert Said APIs Should Never Face the Frontend.

Hiding your API URL is not security. Here is where the advice breaks down and what the person probably meant to say.

This take surfaces regularly in tech communities. A security professional makes the claim: APIs should never be exposed to the frontend. All communication must be server-to-server, inside a private network, invisible to the client. The argument gets picked up, shared and repeated until it starts showing up in code reviews, architecture meetings and junior developer Slack channels as accepted truth.

The problem is not that the person is malicious. The problem is that the claim is incomplete, and incomplete security advice delivered with confidence causes more damage than no advice at all.

Before we get into what is wrong with the claim, we should be fair about what is right. Because there is a real vulnerability hidden inside a poorly worded recommendation, and ignoring that entirely would be just as irresponsible.

The Part They Got Right

There are things that should never leave your backend. Not in a response body. Not in an environment variable shipped to the client. Not in a config file bundled into your build output. Nowhere near the browser.

The credentials that fall into this category are specific:

• Third-party secret keys — Stripe, payment gateways, SMS providers, any service key that carries billing authority or write access to an external system
• Internal service tokens — credentials used for service-to-service communication inside your private network
• OAuth client secrets — the confidential half of your OAuth application registration
• Cloud signing keys and storage credentials — anything that grants privileged access to infrastructure you do not want clients touching directly

These belong server-side. Always. No exceptions, no workarounds.

The data supports how badly developers get this wrong in practice. A 2025 study found over 815,000 secrets harvested from 156,000 iOS apps, with more than 71% of apps leaking at least one credential. These were not breaches in the traditional sense. Developers had embedded service keys directly into mobile binaries that anyone with the right tools could extract without ever touching a server.

That is the real vulnerability. The credential that authorises a third-party action must never land in a client environment, browser or mobile. That part of the advice is correct.

The confusion starts when that specific, valid concern gets generalised into a sweeping claim: that APIs themselves should not be visible to the frontend at all.

What They Got Wrong

Nearly 90% of all web traffic today consists of API calls rather than traditional browser page loads. Every React application, every Vue single-page app, every Flutter mobile client, every Next.js frontend hitting a data layer makes API calls from the client side. That is not a vulnerability. That is how the modern web is architected.

REST APIs are designed by specification to be called over the open internet. The S in HTTPS is doing the protection work, not the invisibility of the URL.

If your security model depends on nobody knowing your endpoint address, you do not have a security model. You have a hope.

OWASP, the organisation that maintains the most widely referenced API security standards in the industry, states explicitly in its guidance that APIs must be treated as public by default, and that all enforcement must occur server-side. Not client-side. Not through obscurity. Server-side, on every single request.

This is the principle the blanket claim misses entirely. It does not matter whether your API URL is visible in a browser network tab. What matters is what happens when a request arrives at that URL without proper authentication, without a valid token, without the right scope. If your server handles that correctly, the URL being visible is irrelevant. If your server handles it incorrectly, hiding the URL is meaningless because a determined attacker will find it regardless.

Security through obscurity has been a rejected concept in the security field for decades. Hiding an endpoint buys you nothing durable. It delays the inevitable while giving developers a false sense of protection.

What the OWASP API Security Top 10 Actually Says

If we are going to talk about API security seriously, we need to look at where real API breaches actually come from. OWASP published its API Security Top 10 in 2023, the most current version available, and it is worth reading carefully for what it does and does not include.

The number one risk, sitting at the top of the list since OWASP first published it in 2019 and unchanged in the 2023 update, is Broken Object Level Authorization. BOLA accounts for roughly 40% of all API attacks and is the most common API security threat found in production systems.

It occurs when an API fails to verify whether the authenticated user is actually authorised to access a specific object. A logged-in user should not be able to change a user ID in a request and silently read another person’s data. That is BOLA. That is the number one problem.

The full list of the ten most critical API security risks, as defined by OWASP:

1. Broken Object Level Authorization (BOLA) — missing per-object authorisation checks on every request
2. Broken Authentication — weak token handling, no expiry, no rotation
3. Broken Object Property Level Authorization — returning more fields than the caller is authorised to see
4. Unrestricted Resource Consumption — no rate limiting or throttling in place
5. Broken Function Level Authorization — admin endpoints reachable by regular users
6. Unrestricted Access to Sensitive Business Flows — automatable flows with no abuse controls
7. Server-Side Request Forgery — the server fetching attacker-controlled URLs
8. Security Misconfiguration — permissive CORS, exposed error stacks, unused endpoints left open
9. Improper Inventory Management — old API versions left alive and unmonitored
10. Unsafe Consumption of APIs — trusting third-party API responses without validation

Not one item on that list is: the URL was visible in the browser. Not one. The risks are entirely about what your server allows when a request arrives, not whether that request could be observed in transit.

Hiding the URL does not solve BOLA. It does not fix broken authentication. It does not enforce rate limits. It does not close unused endpoints. Every real attack vector on that list survives a private URL and collapses against proper server-side enforcement.

Where a Server Layer Actually Helps: The BFF Pattern

Now here is where it gets nuanced, and this is the part the original advice was probably trying to gesture at without the precision to say it correctly.

There is one specific scenario where putting a server between your frontend and an API call is genuinely the right architectural decision. Not because the URL needs hiding. Not because public APIs are dangerous by nature. But because certain credentials cannot safely live in a browser or a mobile binary.

That pattern has a name: Backend for Frontend, commonly referred to as BFF. It was popularised by SoundCloud in 2015 as an architectural solution for serving multiple client types from the same backend without forcing each client to understand all the underlying service complexity.

The rendering model your frontend uses matters here. In server-side rendering, the server generates the HTML and makes API calls internally before anything reaches the browser. In that model, the expert’s instinct is roughly right because the client never calls the API directly. But in client-side rendering, the browser downloads JavaScript and calls the API itself. That is the dominant pattern for SPAs and mobile apps today. Applying SSR thinking to a CSR architecture produces exactly the kind of advice we started with.

The security use case for BFF is specific. When your frontend needs to call a third-party service that requires a secret credential, you cannot put that credential in the client. The browser is, by its nature, a public environment. Anything that executes in the browser is inspectable. Anything bundled into a mobile binary is extractable. So you build a thin server layer that holds the secret, calls the third-party API on behalf of the client and returns only the result.

In an OAuth context, the BFF pattern solves a related problem. Storing access tokens in localStorage is known to be unsafe because JavaScript running in the same origin can read it. The BFF handles the token exchange server-side and returns a secure HttpOnly cookie to the browser instead. The browser sends the cookie automatically on subsequent requests without JavaScript ever touching the token value.

Use BFF when:

• Your frontend needs to call a third-party API that requires a secret key such as payment providers, notification services or data enrichment APIs
• Your OAuth flow for a single-page application requires tokens to be kept off the browser entirely
• You are aggregating multiple internal service responses into a single optimised payload for a specific client type

You do not need BFF for:

• A standard authenticated REST API with short-lived JWTs and proper server-side RBAC
• Internal APIs that already sit behind an API gateway with token validation
• Any situation where someone’s justification is simply that the URL should not be visible to the client

BFF does not prove the original claim right. It is not evidence that all APIs should be hidden from all clients. It is evidence that third-party credentials and long-lived tokens require server-side handling. Those are distinct problems and conflating them is exactly the failure mode that produces bad advice in the first place.

What Actual API Security Looks Like in Production

For developers who want the practical version, here is what security on a public-facing API actually requires. None of it involves hiding URLs.

• HTTPS on every endpoint, no exceptions. Transport encryption is the baseline. There is no argument for HTTP in a production system.
• Short-lived access tokens with rotation. A JWT that never expires is a liability waiting to become an incident. Token expiry should be measured in minutes to hours depending on resource sensitivity, with refresh token flows handling continuity.
• Server-side RBAC enforced on every single request. The server decides what the authenticated user is allowed to do. The client does not get to self-declare permissions. Every endpoint checks, every time.
• Rate limiting per IP and per authenticated user. No endpoint should be callable at unlimited speed. Rate limiting closes the door on credential stuffing, enumeration attacks and denial-of-service attempts.
• Input validation on everything the client sends. Parameterised queries, type checking and length limits. Reject what you do not expect before it reaches your business logic.
• Error responses that reveal nothing useful to an attacker. A 404 and a 403 should look identical to an unauthenticated caller. Detailed stack traces in API responses are reconnaissance material for anyone mapping your internals.
• Proper secret management for downstream credentials. Environment variables at minimum, a secrets manager like AWS Secrets Manager or HashiCorp Vault for anything with financial or administrative impact.

None of this requires a hidden URL. All of it makes a hidden URL irrelevant.

The Actual Problem With Half-Right Advice

Security communities have a specific failure mode worth naming directly. A claim that contains a true insight gets overgeneralised into a universal rule. That rule gets shared by people who understood the emotional conclusion without tracking the technical precision. Junior developers receive it as established wisdom and apply it in contexts that have nothing to do with the original problem.

The original insight here is real. Credentials that authorise external actions must never exist in client environments. That is true, important and worth communicating clearly.

The overgeneralised rule, that APIs should not be visible to the frontend, is not true. It breaks the architecture of the modern web and leads developers to focus on the wrong layer entirely. A developer who spends energy hiding API URLs and skips implementing proper object-level authorisation checks has made their system demonstrably less secure while believing they did the opposite.

That outcome is entirely predictable when advice trades precision for a memorable soundbite.

The URL is the address. The credential is the key. The authorisation check is the lock. Stop hiding the address. Start protecting the key and building the lock correctly.