Locking paid features on the server

The problem we started with#

The tools site showed some tools as Pro, but the decision "is this person Pro?" was made in the browser, from data the browser itself stored. Two more surprises turned up in review:

• The sign-up form didn't create an account on the server; it only saved a "free user" in the browser.
• If a login failed, the page quietly signed the person in as a local "free user" anyway, so any password "worked".
• The Code Studio Pro link pointed at a folder with no start page, so it showed 403 Forbidden for everyone.

The four Pro tools, four different shapes#

Before locking anything we looked at how each tool reaches the user, because that decides how to protect it:

Part 1: the gate#

pro-gate.php is a small script that sits in front of the Pro files:

$p = sgai_verify_token($_COOKIE['sgai_session'] ?? '') ?: sgai_verify_token(sgai_request_token());
$isPro = $p && ($p['plan'] ?? 'pro') === 'pro';
if (!$isPro) {
    // not signed in → sign-in page; signed in but free → upgrade page
    header('Location: ' . ($p ? './?upgrade=1' : 'account.html#signin'));
    exit;
}
readfile($file);   // only Pro members get here

And a rewrite rule in .htaccess makes sure nobody can skip it by typing the file's address:

RewriteEngine On
RewriteRule ^(banner-maker\.html|SGAi-Code-Studio\.html)$ pro-gate.php?t=$1 [L,QSA]

Part 2: why a cookie was needed#

Our logins were tokens kept in the browser's localStorage, sent by JavaScript in a header. That works for fetch() calls, but when you simply open a page, the browser sends no custom headers, so the gate couldn't see who you were.

The fix: at login, the server also sets a cookie:

setcookie('sgai_session', $token, [
  'expires' => $exp, 'path' => '/',
  'secure' => true,     // only over https
  'httponly' => true,   // JavaScript can't read it, so malicious scripts can't steal it
  'samesite' => 'Lax',  // not sent on most cross-site requests
]);

Browsers send cookies automatically with every request to the site, including plain page visits.

Part 3: moving browser-only code behind the gate#

Remove Background's code (about 5 KB) lived inside the public main page. We:

1. Cut the function out exactly (by matching its braces) and checked the cut piece still parsed.
2. Saved it as a private file, delivered only by the gate.
3. Replaced it in the main page with a small loader that asks the gate for the code with the login token, then runs it, or shows "This is a Pro tool. Sign in or upgrade."

Part 4: real sign-up#

The sign-up form now calls the server, which:

• validates the email and password (8+ characters);
• refuses an email that already has an account;
• stores a bcrypt hash, plan free;
• emails a one-time confirmation link (valid 48 hours, stored only as a hash);
• logs the person in (token + cookie).

The "failed login becomes a local account" code was simply deleted. A wrong password now just says so.

Part 5: testing like an attacker and like a customer#

Part 6: surprises with the hosting#

Key takeaways#

• Gate the thing of value: AI calls on the server, page files through a gate, browser code behind the gate.
• Pages need cookies (sent automatically); API calls can use tokens in headers.
• Use HttpOnly + Secure + SameSite cookies for sessions.
• Remove "helpful" fallbacks that bypass security.
• Test as a stranger, a free user, a paying user and a logged-out user.
• When a tool disappears (FTP), use the platform's official API, carefully, one file at a time, with verified backups.

Quick quiz#

Try it yourself#