Accounts and Permissions

The Marquee's website needs to read films and screenings and to write bookings. That is its whole job. But the last page raised an uncomfortable question: if the application is ever tricked into running SQL it didn't mean to — by an injection, or simply by a bug — what else can it do? Could it drop a table? Read every customer's email? The answer depends entirely on something decided long before any attack: what the website's database account is allowed to do.

Databases have their own users and their own permissions, separate from anything the website knows about its visitors. The governing idea carries the most boring name in security — least privilege, meaning every account gets exactly the powers its job requires and not one verb more. Boring, and quietly decisive: it is the setting that fixes the blast radius of every future mistake in advance.

The Database Has Its Own Roster

First, an ambiguity to clear up, because the word "user" now means two different things. The Marquee website has thousands of users — customers with logins and passwords, managed by the application. The database has a much shorter roster of its own: database users, the accounts allowed to open a connection at all. Remember the connection string from Topic 38? It dialed in as marquee_site — that is a database user, and every one of the website's thousand visitors rides in through that single account.

A healthy setup has a handful of database accounts, each with one story. The website connects as marquee_site. Lora's reporting tool, which builds her Monday-morning sales summaries, connects as marquee_reports. And an administrator account exists for the rare occasions someone must change the schema itself. Different callers, different accounts — which only matters because of what comes next.

GRANT, Plainly

Permissions in SQL are handed out per account, per table, per verb, using a statement called GRANT. Here is the website's account being created and given precisely its job:

CREATE USER marquee_site WITH PASSWORD '••••••••';

GRANT SELECT ON films TO marquee_site;
GRANT SELECT, INSERT ON bookings TO marquee_site;

Read the grants as the job description they are: marquee_site may read the film list, and may read and add bookings. The real list runs a little longer — screenings and customers get their SELECTs the same way — but the shape never changes: named verbs on named tables. Now notice everything the statements don't say. No UPDATE. No DELETE. And no DROP, ALTER, or CREATE — the account cannot touch the schema at all, because nobody ever granted it the power. In a database, abilities aren't taken away from accounts; they simply are never given.

If you want a picture to hang this on: hotel keycards. The cleaner's card opens the guest rooms, not the manager's office or the safe room — so a stolen cleaner's card is a bounded problem, and the bounds were set at hiring, not during the theft. That is GRANT: each card opens exactly the doors the job requires. Picture mapped; back to the real terms.

Two Defenses, Stacked

Now replay the last page's nightmare against this account. Suppose the worst: the search box was glued after all, and the hostile input arrives intact, so the database receives DROP TABLE bookings as a real statement over the website's connection. The injected SQL runs as the account that sent it — as marquee_site. And marquee_site was never granted that power:

DROP TABLE bookings;

ERROR: permission denied for table bookings

The exact wording varies by engine; the refusal doesn't. The attack that would have deleted forty thousand bookings instead bounces off a permission check, because a decision made years earlier — two GRANT lines — already determined that this account cannot destroy anything. This is why professionals stack the two defenses rather than choosing between them: parameters prevent injections from happening, and permissions contain whatever slips through anyway. Either one alone has saved companies; both together is the standard.

Separate Accounts, Separate Stories

The same thinking extends across the roster. The reporting account reads everything and writes nothing: if Lora's summary tool is ever compromised, it can leak data — bad — but it cannot corrupt a single booking. A backup job gets an account that reads all tables and touches none. And the humans on a team get personal accounts rather than sharing an admin login, for a reason that has nothing to do with distrust: when something changes at 2 a.m., the database's records should say who, and a shared account makes every answer "somebody". That is the whole posture — one account per job, each telling one story.