Shield: file and access leaks
The most common category of findings is not viruses, but forgotten files: .env, .git, backups, installers. Each poses a danger and should be addressed in a specific order.
The most common category of findings in Shield is not viruses, but unnecessary files accessible to anyone. None of them appear intentionally: they are left after migration, debugging, or updates. This list is where an attack on the site begins.
What is searched for and what are the risks
| Finding | Danger | Why it’s bad |
|---|---|---|
| Open .env | Critical | Database passwords, payment system keys, and emails — in one file |
| File with access | Critical | Configuration with logins is publicly accessible |
| CMS config is accessible | Critical | Direct path to the website's database |
| .git directory is open | High | All source code can be restored, including deleted passwords |
| Backup or dump | High | Downloaded in full: database, users, orders |
| Open installer | High | Allows reinstalling the site over the working one |
| phpinfo or server-status | Medium | Reveals configuration and paths on the server |
| Directory listing | Medium | Shows which files are on the server |
| Server version in headers | Low | Gives scanners hints on which vulnerabilities to try |
Case from our practice
A public installer of a mini-blog on one of our subdomains led to a Google phishing warning upon login — not because the site was hacked, but because the installation page looked like a data collection form. A forgotten file cost more than any vulnerability.Order of elimination
- Remove unnecessary files. Backups, dumps, installers, and debug pages should not be in the root of the site.
- Close service directories at the server level, not through application rules.
- Change everything that could have leaked. If .env or dump was open — consider passwords compromised and change them.
- Remove versions from headers — see server response headers.
- Recheck with a rescan.
Why this also concerns SEO
A hacked site quickly loses positions: search marks it as unsafe, and visitors see a browser warning. Recovery takes weeks. Therefore, security checks should be done not after problems, but before — especially since the basic mode is free.
FAQ
Why is an open .git dangerous?
It allows the entire source code of the site to be restored, including passwords that were once in the repository and later deleted.
What to do if a file with access was opened?
Consider passwords compromised and change them all: database, admin, email, payment keys.
Do such findings affect SEO?
Indirectly: a site hacked through them loses positions and receives a browser warning, and recovery takes weeks.
Was this article helpful?
Thank you! We will consider this in future updates.
Try it on your project
Everything described in the article is available in the dashboard — the registration bonus is already in your balance.
Open dashboard