Why your website might be insecure
The common problems I look for first on a public website, and how to check whether you have them.
Most website break-ins start with something ordinary that nobody noticed. These are the things I check first. You can check most of them yourself, on sites you own.
1. Files that should not be public
A deployment can leave a .git folder, a .env file, a database dump, a backup like site.zip, or a phpinfo.php page on the web server. .env files often hold database passwords and API keys. An exposed .git folder can let someone download your source code.
Check: request /.env, /.git/config, /backup.zip on your own domain. You should get a 404 or 403, not content. Better: only deploy built files, not the whole project folder.
2. Outdated software and plugins
WordPress core, plugins and themes, old PHP versions, forgotten admin tools. Attackers scan the whole internet for known vulnerable versions within hours of a flaw going public. The PHP2Shell case in October 2026 is a recent example.
Check: list what runs, with versions. Remove what you do not use. Turn on automatic updates where safe, and check unsupported versions, since they receive no patches at all.
3. Secrets in the browser
Anything sent to the browser is public. API keys, cloud keys or tokens placed in JavaScript bundles can be read by anyone who opens the developer tools. Source maps left on production can make it easier.
Check: search your built JavaScript for strings like key, secret, token, AKIA. Keep secrets on the server. If a key was ever public, rotate it. Deleting it from the code is not enough.
4. Open storage
Cloud storage buckets or blobs set to public, database snapshots shared by mistake, upload folders that list their contents.
Check: review sharing settings on every bucket and snapshot. Try opening a file URL in a private window. Turn on your provider’s “block public access” setting at the account level.
5. Subdomain takeover
You point shop.example.com at a hosting service, cancel the service, and leave the DNS record. Someone else can claim that name on the service and serve content on your domain.
Check: list your DNS records and look for ones that point to services you no longer use.
6. Weak or exposed admin panels
/admin, /wp-login.php, a database tool or a dashboard reachable from anywhere, protected by a password that is short, reused, or never changed from the default, with no multi-factor authentication and no limit on login attempts.
Check: can you reach your admin login from a phone on mobile data? If so, restrict it to your network or put it behind a VPN or single sign-on, and add MFA.
7. Access control that only exists in the interface
A button is hidden for normal users, but the server still answers if you call the address directly. Or user A can read user B’s data by changing a number in the URL. Scanners rarely find this. It needs someone to test with two accounts.
Check: with two test accounts, try opening an object that belongs to the other one. The server should refuse.
8. Missing security headers and weak cookies
Headers like Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options and a framing rule tell the browser to limit what a page can do. Session cookies should be Secure, HttpOnly and have a SameSite setting. These are rarely the whole problem, but they limit damage from other bugs. MDN documents each one: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers.
Check: look at the response headers in the browser’s developer tools, or fetch the site with curl -I.
9. Forgotten systems
Old staging sites, test servers, retired apps and marketing microsites still running. They are often outdated and rarely monitored. A certificate record can reveal them.
Check: make a list of every domain and subdomain you own and what each one is for. Remove what is not needed.
10. No way to be told
If someone finds a problem, how do they reach you? A security.txt file at /.well-known/security.txt (RFC 9116) gives a contact address.
What to do with this list
Fix what you can find. For the rest, an outside view helps, because you are checking your own work. An external attack surface review covers items 1 to 6 and 9, and application testing covers 7 and 8.