Is your admin page online? What to put in front of it

If your admin panel or dashboard lives on the same public address as your site, anyone can find it, so put it behind an extra sign-in or on an address only your team uses. Then make every data source your app uses answer only people who are signed in and allowed.

What does it mean when an admin page is online?

Most sites have parts only you should use, like an admin panel, a dashboard or the connection your app uses to read its database. Lockpick's docs say sign-in pages, admin panels and data connections that anyone can reach deserve extra care.

Before you change anything, work out which of these cases fits your admin page.

How do I check?

Start by looking the way a stranger would. Open a private browser window, stay signed out, and visit the address you use for your admin panel. If it shows anything beyond a sign-in form, treat it as urgent.

Lockpick checks your site from the outside, the way a stranger or an attacker would find it. Lockpick never signs in to your site and never looks at anything behind a login.

A Deep scan reads up to 30 readable pages and 20 scripts, files that should not be public, admin areas, and your API if you have one. It sends at most 200 requests to your site. Requests are spaced out, and a scan stops early if your site slows down, fails or refuses. To run Deep, you prove you own your site and approve each scan.

A scan tells you what answered, with the request it sent, so your developer can repeat it. When the report arrives, open your things to fix and look for anything that answered without signing in.

Check your site

How do I fix it?

1. Add an extra sign-in. When you can, put the admin panel behind an extra sign-in or on an address only your team uses.
2. Lock every data source. Check the access rules of every data source your app uses, so each one only answers people who are signed in and allowed.
3. Turn off developer tools. Turn developer tools off in the live site.
4. Protect the server as well as the page. Make every admin route on your server refuse a caller who is not signed in as an admin. Don't count a hidden menu link as protection. If you want the detail, read API endpoint without authentication.
5. Check again. Run Check again on the same site and confirm that your admin page and its data no longer answer a signed-out visitor.

Fix it with your AI

Paste the prompt that matches your builder. For more, read Fix security issues with your AI builder.

My app has an admin page that anyone can open. Please:
1. Find every admin page and admin-only component in this project.
2. Make them render only for a signed-in user whose account has an admin role, and send everyone else to the sign-in page.
3. For every database table or function the admin page reads or writes, add access rules so only signed-in admins can use them, as well as protecting the page itself.
4. Turn off any developer or debug tools in the published build.
5. List what you changed and which pages and tables are now admin only.

Lock down the admin area of this app.
1. Find every admin page, admin API route and server action.
2. In each admin route, check the session on the server. Return 401 to a caller who is not signed in and 403 to a signed-in user who is not an admin. Read any secrets from environment variables, never from client code.
3. Make the admin pages redirect signed-out visitors to the sign-in page.
4. Check the access rules on every data source the admin area uses so each one answers only signed-in, allowed users.
5. Make sure developer tools and debug output are off in production.
6. Summarise each file you changed.

My admin panel is reachable from the public internet. Put it behind an extra sign-in, or move it to an address only my team uses if this setup supports it. Make every admin route on the server refuse callers who are not signed in as an admin. Review the access rules of every data source the app uses so each one only answers signed-in, allowed users. Turn developer tools off in the live build. Then tell me what you changed.

What a check cannot tell you

A Lockpick report is not a certificate and not a full penetration test. It covers what that scan could see on that day. A report marks anything it couldn't check as not checked, never as passed.

Don't read a clean report as proof that your admin sign-in is strong, because Lockpick never looks at anything behind a login.

OWASP's testing guide says automated tools are built for applications in general, not for your custom code and business rules. They can find many common problems, but they often lack the application-specific context needed to detect deeper flaws. Decide who should reach your admin panel and what each admin may do, then test it while signed in. For a tester's view, read the OWASP section on finding admin interfaces.