Key Takeaways
- Keep backups, database exports, credentials, logs, and private documents outside public directories or behind proper access controls.
- Protect administrator access with MFA, rate limiting, secure password recovery, session revocation, and least-privilege permissions.
- AI and free security tools can support reviews, but only authorized testing and verified evidence can confirm a security issue.
Is Your Website Secure? How to Check Exposed Files and Login Risks
Your website can look professional, load quickly, and process customer orders while still exposing a database backup or leaving an old administrator account active.
These weaknesses rarely announce themselves. Everything may appear to work until someone accesses information they should never have been able to reach.
A useful security review starts with two questions: What can visitors access, and who can sign in?
This guide helps website owners investigate both. It covers private files, login protections, password recovery, and sessions, with practical checks you can discuss with your developer or hosting provider.
Only test websites you own or have explicit permission to assess. Use dummy accounts and a staging environment for tests that could affect access or availability.
Start Here: What Should You Check First?
Work through these questions in order:
| Check | What you want to establish |
|---|---|
| Private files | Backups, credentials, and customer documents cannot be retrieved without authorization |
| Administrator access | Every privileged account has a current owner and a legitimate purpose |
| Login protection | MFA and controls against automated guessing are configured |
| Password recovery | Reset links expire, work once, and cannot be used to take over another account |
| Sessions | Users can end access on other devices, and logout actually removes access |
Record each result as verified, needs attention, or not checked.
“Not checked” matters. An unfamiliar setting is an unanswered question, not evidence that your website is secure.
1. Check Whether Private Files Are Public
Imagine a developer creates a database backup before updating your website. The update succeeds, but the backup remains in the folder your server publishes online.
If that file is accessible without authentication, someone who discovers its address may be able to download it.
Start by asking your developer or hosting provider to identify exactly which folders and storage locations are public. On traditional hosting, the website directory may be called public_html. Other platforms publish a configured folder or generated build output.
Review those locations for:
| Item | Why it needs attention |
|---|---|
| Database exports | May contain customer records or password hashes |
| Backup archives | May combine source code, credentials, and business data |
| Environment files | May contain private service credentials |
| Debug logs | May reveal internal details or sensitive request data |
| Git metadata | May expose source history and previously committed secrets |
| Customer documents | May require individual access permissions |
Verify the access rules, not just the filenames. A file stored on the server is not necessarily exposed, and a harmless filename does not make sensitive content safe.
Use configuration reviews and harmless staging files to check restrictions. Avoid downloading real customer information simply to demonstrate exposure.
If you find an exposed file, restrict access and investigate what it contained. Rotate any compromised credentials.
Disabling Directory Listings Is Only One Step
A directory listing displays the files inside a folder. Turning it off can prevent casual browsing, but someone may still retrieve a file using its exact address.
Ask two separate questions:
- Can visitors list the folder’s contents?
- Can an unauthorized visitor retrieve a private file directly?
Both need an answer.
2. Review Who Can Administer Your Website
Open your website’s user-management page and review every administrator.
For each account, establish who owns it, why it needs access, and whether its permissions match the person’s current responsibilities.
Remove unnecessary access, including unfinished invitations and accounts belonging to former contractors.
Repeat this review for your hosting account, domain registrar, source-code repository, and connected services. A clean website user list does not tell you who controls the infrastructure around it.
Keep individual accounts wherever possible. Shared administrator credentials make it harder to revoke one person’s access or understand who made a change.
3. Strengthen the Login Page
Enable multifactor authentication for administrators and review the recovery process for lost authentication devices.
Next, ask your developer how repeated failed login attempts are handled. Appropriate controls may include account-aware throttling, progressive delays, and monitoring. Test documented limits with a dedicated staging account.
Review login and recovery messages, too. Responses that reveal whether an email address is registered can help attackers identify accounts.
A recovery message such as “If an account exists, we’ll send instructions” reduces that disclosure. Response timing and other behaviour also need consideration.
These protections are covered in the OWASP Authentication Cheat Sheet.
Question to send your developer:
“Please show me how administrator MFA, login throttling, and account recovery are configured, and what evidence confirms they work.”
4. Test the Password Reset Process
Password recovery deserves the same attention as login. A weak reset process can undermine an otherwise strong password.
Use a test account and an email address you control:
- Request a reset link.
- Use it to change the password.
- Confirm that the old password no longer works.
- Try the used reset link again.
- Separately verify the configured expiration period.
The token should be unpredictable, time-limited, and invalid after use. Reset requests also need protection against abuse.
Check that account-change notifications arrive and that recovery does not disclose whether an address is registered. These expectations follow OWASP’s password recovery guidance.
A successful reset proves only the behaviour you tested. It does not establish that every recovery route is secure.
5. Check What Happens to Existing Sessions
Changing a password may leave another browser signed in, depending on the application’s design.
Test this with two browsers and a dummy account. Sign in through both, change the password in one, and attempt a protected action in the other.
Then test any “sign out of all devices” feature. An old page remaining visible is different from the server accepting a new authenticated request.
Ask your developer to review session expiration, revocation, rotation after authentication, and cookie protections. For cookie-based sessions, relevant settings include Secure, HttpOnly, and an appropriate SameSite policy.
The OWASP Session Management Cheat Sheet explains these controls.
6. Ask Where Private Credentials Are Stored
A working integration does not show whether its credentials were handled correctly.
For each connected payment, email, storage, or database service, ask:
- Which credentials are intended to be public?
- Which must remain private?
- What permissions does each credential grant?
- How would we revoke it if it leaked?
Have your developer review what the deployed browser application contains, alongside server configuration and source history.
Do not assume that a setting labelled “environment variable” is automatically private. Establish whether the platform includes its value in the browser build.
If a private credential was exposed, removing it from the latest code is only part of the response. Revoke or rotate it and review relevant activity.
Can AI Help With This Review?
AI can help organize evidence, explain unfamiliar settings, and draft questions for your developer.
Give it sanitized configuration excerpts, relevant code, and test results. Remove passwords, private keys, customer records, and session tokens.
Use this prompt:
Review the sanitized website security evidence below. For each concern, identify the supporting evidence, explain the possible impact, recommend a fix, and describe a safe verification step. Separate confirmed problems, suspected problems, and areas that remain untested. Focus on exposed files, administrator access, authentication, password recovery, and sessions. Do not infer that an untested control works.
Treat its output as a review to verify. A plausible explanation is not proof of a vulnerability—or proof of security.
What Should You Fix First?
Prioritize findings using the evidence and potential impact:
| Finding | Immediate next step |
|---|---|
| Public customer records or private credentials | Restrict exposure, preserve relevant evidence, and investigate |
| Unauthorized administrator access | Remove access and review account activity |
| Weak authentication protections | Configure controls and verify their behaviour |
| Unclear or undocumented settings | Assign an owner to investigate |
If sensitive information may have been accessed, get qualified help to assess the incident and any applicable obligations.
Your Review Is Finished When You Can Show Evidence
“Security plugin installed” is not a verified outcome. “Private document access denied for an unauthorized test account” is.
Keep a short record of what you checked, when you checked it, the result, and who owns any follow-up. Repeat relevant tests after changes to hosting, authentication, permissions, or integrations.
These checks cover important file-access and login risks. Broader website security also requires attention to application code, software updates, backups, monitoring, and recovery.
Start with one concrete result: verify that private information stays private, then verify that account access works as intended.