Are settings or deployment files readable on your live site?
The deployment file check looks for files used to configure, build or deploy your app that anyone can read at a public address. A match is confirmed by the file content, not just by an answer.
What does this check look at?
It looks at whether files used to configure, build or deploy the app are readable at public addresses, judged by their content rather than by an answer alone. Nobody links to them, so they feel hidden. They aren’t. A scan checks a short, careful list of common file names and never downloads more than it needs to confirm one is there.
Only a Deep scan runs it, after you prove you own the site.
What does a result mean?
| What the report shows | What it means | What to do |
|---|---|---|
| High finding | A file with credentials or source history was served. | Remove it, then rotate every secret it held. |
| Medium or info finding | A configuration or build file was served. | Remove it and fix the deploy so it only publishes the built site. |
Only enough is read to recognise the file, so it does not show access to the systems the file names. A clean result means nothing was found in what the scan read. It does not prove the problem is absent from parts the scan never sees.
How serious is a finding?
Fix this first when it is confirmed. Anyone could use a finding of this kind on their own, with no victim and no second step. Confidence starts high, because a response from your site shows the thing itself. The report lists what to fix by how directly someone could use it, not by the severity label. Delete the file from the live site, then ask whether anything in it needs replacing.
What does a confirmed finding have to show?
| Part | For this check |
|---|---|
| Where it starts | Anyone on the internet, with no account, cookie or credential |
| The protection that should stop it | The server should refuse deployment and configuration files at their usual paths |
| What is reached | The file was served at a fixed public path |
| What follows | The configuration, history or credentials the file holds |
Which standards does it relate to?
| Standard | Reference |
|---|---|
| OWASP Top Ten | A02:2025 Security Misconfiguration |
| CWE | CWE-538 |
Each one is a related control, not a verification. A scan sees what anyone online can see, so it never proves a whole requirement is met.
Fix it with your AI
Removing the file is half the fix. Anything it held, such as passwords and keys, must be replaced too.
My live site serves a deployment or settings file publicly: [paste the file type and evidence from the report]. Remove it from what my host serves, and fix my build or upload step so only the built site output is published, never the project folder, dotfiles or version control data. List every secret the file contained so I can rotate each one with its provider, and add a deploy check that fails if such files appear again.How to check
Say Atlas, our example app at atlas.example, was uploaded as a whole project folder to a plain web host. A Deep scan confirms a settings file by its content and stops reading there.
Deep scans come with the Deep plan, and pricing shows what it includes. Pulse or Deep explains what each scan reads, and the full list of checks shows the rest.
Questions people ask
Which file names does the scan try?
Lockpick does not publish its list. It is short, it covers files that commonly hold settings, credentials or source history, and each read stops once the file is recognised.
I deleted the file. Am I done?
Not yet. Anyone may already have it, so replace every password and key it held, then check again.
Run this check on your site
Only a Deep scan runs this check, once you prove you own the site. Deep walks your whole site, the scripts it loads and your API surface.
Run a Deep scanSources
- Files you forgot were public Lockpick docs, read on October 7, 2026
- How we rate findings Lockpick docs, read on October 7, 2026