Why the frontend gate fails, and the real one doesn't
Ask an AI assistant to make a page private and it will cheerfully write you a passcode box that protects nothing. This walkthrough builds that gate, lets you break it yourself in about ten seconds, and then shows what a real gate does differently. One idea runs through all of it: a gate is only real if the check happens somewhere the visitor cannot reach, and the browser is not such a place.
Module 01
What a gate is supposed to do
When you "lock" a web page, what actually happens?
Before anything can be judged real or fake, the picture has to be right: what a visit is, what gets sent, and who decides.
A visit is a request and a response
A visitor's browser sends a request: give me this page. A computer somewhere sends back a response: here are the files. That is the whole transaction. Everything the page needs in order to work, the text, the styling, the scripts, arrives in that response and lands on the visitor's own machine. Once it has landed, it is theirs. They can read it, save it, and change it, and nothing you write into the page can stop them.
This is not a flaw to be patched. It is how the web is built, and it is why the browser can never be trusted to keep a secret.
So which side is each piece on?
The promise a gate makes
A gate promises one thing: people I have not chosen do not get to read this. Hold that promise up against the request and response picture and the test writes itself. If the protected content is inside the response, the promise is already broken, whatever happens afterwards. A real gate has to act earlier than that; it has to change what gets sent, not what gets shown.
Decision before delivery, or decision after delivery. Everything in this walkthrough sorts into those two.
Module 02
The gate that isn't
Myth we'll unpick: "telling the AI to make it secure makes it secure"
Ask a coding assistant for a private page and this is what comes back. It looks like a lock. Now go and break it.
What the assistant writes for you
The generated answer is nearly always the same shape. A passcode box on the page; a line of JavaScript holding the correct passcode; and, on a match, either a hidden section made visible or a redirect to the "protected" page. It runs. It rejects a wrong guess. It feels like the lock you asked for, and that feeling is the entire problem, because every piece of it was downloaded to the visitor before they typed a thing.
Nothing here is a criticism of the assistant. It answered the question it was asked: make a page that asks for a passcode. Whether that is access control is a question the person asking has to know to ask.
Break it yourself
The page, as a visitor sees it
Private
Enter the passcode to continue.
You are through.
This is the "protected" content. It was sitting in the response the whole time, waiting for a line of JavaScript to stop hiding it.
What the browser downloaded
Every visitor can open this panel. It is the developer tools built into their browser, two keystrokes away.
Three separate failures, not one
●The passcode is readableIt travelled to the visitor inside the page's own code. View source or open developer tools and it is simply there. Hashing it does not save you either; the hash arrives too, it can be tested against guesses offline, and the checking logic sits right beside it.
●The content was never withheldIf the script hides a section, that section is in the downloaded HTML. If it redirects to another page instead, that page is usually served to anyone who requests its address directly, with the gate never involved at all.
●The check itself can be rewrittenThe comparison runs on the visitor's machine, so the visitor can change it. They do not even need the passcode; they can make the code stop asking.
●What it is genuinely good forKeeping a page out of the way of a casual passer-by, and nothing more. Build one once so you can break it; that is the value, not the protection.
The content was always on the visitor's machine. The check was theatre.
Module 03
The real pattern
A claim to test: a real gate decides before it sends.
Same passcode box on the outside. Everything different behind it.
The shape of a real one
The form does not check anything; it submits the guess to a small program running on the server. That program compares the guess against a secret the visitor has never received, and answers yes or no. On yes, it hands back a token in a cookie. From then on, the token travels with each request, and the protected content is only put into a response when a valid token came with the request that asked for it. The visitor never holds the passcode. They hold a pass, and the pass is checked by the venue.
On a static site this program is usually a serverless function; the host runs it on demand and you do not manage a server. The pattern is the same wherever it runs.
Four properties, four reasons
Each of these gets described as a best practice and then never explained. Guess the reason, then reveal it.
What it still will not do for you
A signed cookie stops forgery, reading, and script-based theft. It does not stop somebody guessing. Nothing in the pattern limits how many attempts a visitor may make, so a weak shared passcode is still a weak shared passcode. Choose one that is long and unguessable, and consider limiting attempts. And be honest about the model: one passcode shared with a group is only ever as private as the least careful person holding it.
That is the mechanism. Now the question of whether you should build it at all.
Module 04
Choosing without over-engineering
This module covers the three genuine options for the common case: showing a site to people you choose, without running a subscriber system. All three are real. They differ in what they cost you, in effort and in reach.
Three real options, compared
Costs are described in shape rather than in dollars on purpose. Plan names, tiers and prices for these services have all changed within the past year; the course page carries the dated figures and the note to re-verify them before quoting them to anyone.
One to know about, not to reach for
Hosts have historically offered built-in account systems that let a static site have real logins. At least one prominent example was announced as deprecated in early 2025, then partially walked back to "still supported", with no active development since. That is the worst state a dependency can be in: alive enough to be recommended in old tutorials, dead enough that nothing will be fixed. Treat anything in that condition as legacy; do not start something new on it.
The general lesson outlasts the particular product. Before you build on a convenience feature, look for signs it is being maintained, not just signs it exists.
Where the secrets live
You have built the real gate. The signing secret and the passcode have to live somewhere. What is wrong with putting them in the code, in a repository you have set to private?
Private is not the same as secret, and history is forever.A secret committed to version control stays in the history even after you delete the line, so anyone who ever gains access to the repository gains the secret, including any future you who makes it public by accident. Secrets belong in the host's environment variables, which the function can read at run time and the repository never sees. Keep the repository private as well, because the gate's logic is a map of how to get past it; but treat that as the second lock, not the first.
Why this matters
You now hold a test you can apply to anything, not just passcodes. Ask where the decision is made. If the answer is "in the visitor's browser", it is not a control; it is a request politely worded. Anything the browser can check, the visitor can read and rewrite. That single sentence covers hidden prices, disabled buttons, client-side validation, feature flags and every locked page on the web, and it is the difference between building something that looks careful and building something that is.
Sources used: the client-side versus server-side principle and the cookie attributes here (signed tokens, HTTP-only, Secure) are standard web security material, set out in the access-gates resource written for this course and its research brief, checked August 2026. The three options, their trade-offs and the deprecated-then-walked-back host identity product come from that resource, which draws on the vendors' own pricing pages, documentation and changelogs; the paid-tier restriction on host passwords is from the vendor's blog post of 3 November 2025, and the edge one-time-PIN allowance from its Zero Trust documentation. Prices are deliberately not quoted here because they change frequently; the dated figures and confidence labels are in the course resource. Nothing in this card is a working bypass; every panel is a closed simulation.