Is your website handing out its own source code?
If a site is deployed by copying or pulling a working copy, the repository comes with it. Serve that folder to the public and you have published every line you have ever written, including the passwords you took out again afterwards.
Seconds. No account, no card, no permission needed. It reads only what your website already shows every visitor, and it keeps nothing.
How a repository ends up on the web
Nobody decides to publish it. It arrives with the deploy.
A git repository keeps its whole history in a folder called .git, at the top of the project. That folder is not a build artefact and it is not configuration. It is the archive.
Three ordinary habits put it in the web root:
- Deploying by pulling. Somebody logs into the server, runs a pull in the site folder, and the site updates. Convenient, and the archive is now sitting under the document root.
- Copying the project folder up. Drag the whole working copy over by FTP or rsync and the hidden folder travels with it, because it is hidden from the file manager and not from the server.
- Pointing the document root at the project. Frameworks ship a
publicorwebdirectory precisely so this cannot happen. Point the virtual host one level too high and everything above it becomes reachable.
None of those is careless. All three are how a great many working sites are run, which is why scanners look for this address on every website they see, all day, every day.
Why it matters more than it sounds
It is not the current code. It is every version of it.
The worst part is not that a stranger can read your source. It is that they can read the parts you removed.
A password committed by accident in March and taken out again in April is still in the March commit, and the March commit is still in the repository. Rewriting the current file changes nothing about the history that sits behind it. If the history is public, the password is public, and it has been since March.
Credentials
Database passwords, mail credentials, payment keys and API tokens, from any commit ever made.
The map
Admin paths, internal hostnames, staging addresses, the shape of the database, and the names of everything not linked from the site.
Your dependency list
Exact versions of every library you use, so somebody can look up which of them has a published vulnerability rather than guessing.
Who did what
Every commit carries a name, an email address and a timestamp. That is a staff list and a working pattern.
The boundary, stated plainly
What this check does, and what it refuses to do.
It asks your website for three addresses and reads the first few hundred bytes of each answer. That is the entire test. Anyone with a browser can do the same thing, which is why it needs no permission from you.
It does not download your repository. It never asks for an object, never reconstructs a file, and never shows you the contents of anything it read. It reports whether a repository is readable and nothing further, because proving the point by taking a copy of somebody's source code is not a demonstration, it is the thing being warned about.
It keeps nothing. No account, no cookie, no record kept against your name. The address you type appears in the page address so that you can send the result to whoever looks after your website, and that is the whole of it.
It checks one thing. A clear result here means one specific door is shut. It says nothing about your login, your forms, your database or anything else.
The rest of the site
Nine guides to the parts of git that cost you something.
Written for somebody with a live website to worry about rather than for somebody learning git from scratch. The safe answer before the clever one, and a straight line on which commands rewrite history.
Undoing almost anything
One table, from unstaging a file to recovering a commit you deleted. Everything that cannot be recovered is marked.
A password is in your history
Why changing the credential is the fix, and why rewriting the history mostly is not.
Why your ignore file is not working
Because it does nothing about a file git has already been told to track.
Branches, merging and rebasing
What a branch actually is, and the one rule about rewriting history you must not break.
Who runs this
Hosting, domains, email and databases since 1996. Websites are the small part.
git.guide is run by Dalaric, a one person consultancy in Dorset. The free check stays free: it sells nothing, it needs no account, and it is how a good many people meet us.
If the check found something, the fix is on this site and it costs nothing. If you would rather somebody looked at the whole of it instead of one door, that is a piece of work Dalaric does.
Website Security Report
One authorised automated test of a web application, run with your written permission, then triaged and written up in plain English by a person. A thirty minute call to go through it, and a retest after the fixes if you want one.
£595 plus VAT, for one web application.
Cloud infrastructure and operations
If this check found a repository in your web root, the deploy is the real finding. AWS architecture, multi server estates, Cloudflare, Linux, backup and disaster recovery.
Integration and data
The systems behind the website. APIs, database performance, migrations and reporting pipelines, designed by somebody who knows what is underneath.