Exposed Git Metadata Check — Does Your Deployed Site Serve Its Git Files?
DevMeth checks the 48 known AI-code failure patterns — not a penetration test or a security guarantee.
What the issue is
A deployed site that serves its .git directory and metadata hands anyone your repository — including historic secrets and internal paths — straight over HTTP.
Why AI tools generate it
AI deploy steps can ship the whole project folder, including the hidden .git directory, straight to a public host without noticing.
How DevMeth detects it
A read-only live probe requests /.git/config and /.git/HEAD and checks whether either returns git metadata instead of a 404/403/redirect.
Your deployed site serves its git metadata to anyone
WHAT WE FOUND
GET /.git/config — 200 — metadata served publicly
The fix, in three steps
Exclude hidden and source-control directories from your deploy, and add a deny rule for /.git paths. Three steps.
Run a free scan and each finding carries a paste-ready fix prompt you can act on.
Try a free scanFAQ
Why is serving .git dangerous?
A fetched .git directory lets an attacker reconstruct your repository, including code, internal paths, and any secrets still in history.
How is this probed?
A read-only request fetches /.git/config and /.git/HEAD and checks whether either returns git metadata.
What is the fix?
Exclude hidden and version-control directories from the deploy and block /.git paths at the server or CDN.
DevMeth checks the 48 known AI-code failure patterns — not a penetration test or a security guarantee. A clear result means each known pattern was checked and found clear or not applicable for your app; it is not a guarantee of security.