The tools that can do anything

The most dangerous page you will write

Your admin panel can read every message, change any record, refund any payment and delete any account. It was built quickly, it has fewer tests than the rest of the application, and it usually has no audit trail. It is also the page an attacker most wants, and the page from which an internal mistake does the most damage.

A useful way to hold it: an admin surface is not a feature, it is a set of powers granted to people, and every power needs a reason, a record and a limit.

Fail closed, and return nothing

Access should be an explicit allowlist: a list of accounts, checked on every request, defaulting to refusal. Not a role field that could be empty, not a check on an email domain, not the absence of a flag.

And for an unauthorised caller, answer 404 rather than 403. A 403 confirms the path exists, which is exactly what somebody probing wants to learn. This is a rare case where hiding is worth the confusion, because the audience for the truthful answer is nobody legitimate.

Put a second factor in front of it. If your identity provider supports it, require re-authentication for the admin session specifically, so a stolen ordinary session does not carry admin power.

Log every action, permanently

An admin audit log is a different thing from application logs: append-only, retained far longer, and containing who did what to which object at what time, with the before and after values where practical.

{"ts":"2026-09-06T11:20:04Z","actor":"handle:priya","action":"account.suspend",
 "target":"identity:8812","reason":"report #4471","before":{"status":"active"},
 "after":{"status":"suspended"},"request_id":"9ab3f1"}

The reason field is worth insisting on, and worth making mandatory. It changes behaviour: an action that must be justified in a sentence is an action somebody thinks about first. It is also the difference between a defensible moderation decision and an unexplained one when the affected person asks.

Write the log before performing the action, or in the same transaction. A log written afterwards is missing exactly the entries where something went wrong.

Impersonation, which you will eventually want

“View as this user” is useful for support and dangerous. If you build it:

• Log the start and end, with the reason.
• Make it visible in the interface, to both parties where possible, so nobody forgets which account they are in.
• Keep it read-only unless there is a specific reason not to, and log every write separately if there is.
• Time-limit the session.
• Never impersonate to read private content without a documented reason: a support ticket from that user, or a legal obligation. “Curiosity” is how staff-access scandals begin at every company that has had one.

Least privilege for the humans, too

Not everybody who needs admin needs all of it. Three tiers usually cover a small team: read-only support, moderation actions, and destructive or financial operations. The third tier should be a short list.

For dangerous operations (bulk deletion, database access, refunds above a threshold) the pattern is break-glass: the power exists, it is not held by default, obtaining it is a deliberate act that is logged and announced to the team, and it expires. This is the same idea as a rotating key, applied to authority.

Do not run destructive operations from a text box

An admin page with an arbitrary SQL box is a shell on your production database with a nicer font. If people need to run queries, give them a read-only database user, a saved-query interface, or a proper tool (Metabase is free and does this well) and keep writes in named operations with a confirmation and a log entry.

For bulk actions, three habits: preview what will change and show the count before executing, require typing the count or the object name to confirm, and make the operation reversible or at least recoverable from the audit log.

Review who has access, on a schedule

Access accumulates. A contractor, a former colleague, a personal account added during an incident. Once a quarter, print the list of admins and confirm each one line by line, then remove the rest. Add the same review for API tokens, database users and cloud accounts.

This is dull and it consistently finds something, which is why it belongs on the same quarterly calendar as the restore drill and the key rotation.