The site's source code repository is public

SeverityCritical

ScopeWhole site

EffortSmall

Verified bySecurity scan (weekly, or Re-scan)

Rule keysec_exposed_git

Short answer

Files from a version-control folder such as /.git/ can be downloaded from your site. Even without directory listing, free tools rebuild the complete source code and commit history from these files, including any password or key that was ever committed. Block the folder, deploy without it, and change every secret found anywhere in the repository.

Why it matters

Source code shows an attacker exactly how your site works: admin paths, database queries, upload handlers, custom plugins and their bugs. The history goes further, because a password removed from the code years ago is still in old commits. Exposed .git folders are scanned for at internet scale and are a common starting point for full site takeovers.

A .DS_Store file (created by the macOS Finder) holds no code, but it lists the names of the files in its folder, which can point to backups and hidden admin scripts; Glimana reports it under this check with the same severity. None of this affects rankings directly; a resulting compromise does.

How Glimana detects it

Glimana requests /.git/HEAD, /.git/config, /.svn/entries and /.DS_Store over HTTPS and reads only the first 2 KB of each. A file counts as exposed when the answer is 200 or 206 and the content has the real format: ref: refs/heads/… for HEAD, a [core] section for config, the Subversion entries format, or the binary .DS_Store header. HTML pages and answers identical to a random non-existent address are ignored. Glimana stops there and downloads no repository objects. An exposed repository is Critical and also sends an immediate alert e-mail; a lone .DS_Store, which only leaks file names, is Medium.

How to fix it

Watch out

Removing .git from the server stops the leak but does not undo it. Assume the code and its full history have been copied: rotate every credential that appears anywhere in the history, not only in the current files, and review the code for weaknesses that are now known to others.

Find the finding in Glimana. Open Security; this check is in the Exposed files group, with the evidence from the last scan under its title. The same problem is listed under Issues › The site's source code repository is public.
Apply the fix on your platform.

DeploymentApacheNginxCloudflare

Do not deploy by running git clone or git pull inside the web root. Upload a copy without version-control data instead, for example rsync -a --exclude='.git' --exclude='.DS_Store' ./ user@server:/var/www/site/. If you must pull on the server, keep the repository outside the web root and point the web root to a subfolder such as public/. Remove stray Finder files with find /var/www/site -name .DS_Store -delete.

In the virtual host or .htaccess: RewriteEngine On and RewriteRule "(^|/)\.(?!well-known/)" - [F]. This denies .git, .svn, .DS_Store and every other hidden file while keeping /.well-known/ for certificate renewal.

In the server block, before other regex location blocks: location ~ /\.(?!well-known) { deny all; }, then nginx -t && systemctl reload nginx.

As a temporary shield: Security › Security rules › Create rule › Custom rules, expression (http.request.uri.path contains "/.git") or (http.request.uri.path contains "/.svn") or (http.request.uri.path contains ".DS_Store"), action Block. Fix the server as well; requests that bypass Cloudflare are not covered.
Check it in Glimana. Press Re-scan on the Security page (up to two scans an hour) or wait for the weekly scan on Sunday; the problem closes when the check passes.

How the fix is verified

After fixing, press Re-scan on the Security page (or wait for the weekly Sunday scan); the problem closes as soon as the check passes.