A short story about finding a security hole on an Indonesian government website

The Beginning: Just Curious About .git

So there I was, doing some casual security testing (within reasonable boundaries, of course), when I opened:

https://rendom.rendom.target.go.id

Nothing special. Looks like a typical government website.

But I got curious… many developers these days forget to delete the .git folder when deploying to production. The .git folder is where all the code history, configuration, and sometimes even passwords are stored.

"Eh, let me just check."

First Attempt: Blocked 🤔

I tried accessing:

https://rendom.rendom.target.go.id/.git/

Result?

403 Forbidden.

"Alright, maybe it's safe. They blocked it."

I almost closed the tab and moved on.

But Wait…

I remembered one lesson from bug bounty hunting:

Sometimes a 403 on the root folder doesn't mean the files inside are safe.

So I tried accessing specific files inside the .git folder:

  • /.git/config
  • /.git/index
  • /.git/HEAD

And the result? Success. All of them loaded.

What I thought was "safe" turned out to be just a fence with the gate wide open.

The root folder was blocked from showing directory listings, but individual files inside were freely accessible.

Time to Bring Out Git-Dumper

After confirming the files were accessible, I ran:

bash

git-dumper <https://rendom.rendom.terget.go.id/.git/> dumped-repo/

What happened in the next 5 minutes?

  • Entire commit history (including deleted ones ❌)
  • Full source code down to config files
  • And the most dangerous one…

/application/config/database.php

Found it!

The contents looked something like this:

php

$db['default'] = array(
    'hostname' => 'localhost',
    'username' => 'root',
    'password' => 'SuperSecretPassword123',
    'database' => 'eturjawali_db'
);

Host, username, password, database name — complete package.

The Impact? Don't Ask.

With this file, an attacker could:

  1. Read the entire database (citizen data, reports, etc.)
  2. At minimum, steal the source code to find other vulnerabilities
  3. Log in using those credentials if the database is accessible from the outside

I didn't proceed to the database — testing ethics and responsibility. But if a malicious actor found this? Big trouble.

Why Did This Happen?

Two root causes:

  1. The .git folder still exists on the production server (a cardinal sin in deployment)
  2. The 403 rule only applies to the root folder — like installing an alarm on the garage door while leaving the kitchen window wide open

The server configuration essentially looked like this:

✅ /web/.git/ → 403 Forbidden

❌ /web/.git/config → 200 OK

Clearly inconsistent.

How to Fix It?

Simple. The proper configuration should be:

Nginx:

nginx

location ~ /\\.git/ {
    deny all;
    return 404;
}

Apache:

apache

<LocationMatch "^/.*\\.git/">
    Require all denied
</LocationMatch>

Or the simplest solution: delete the .git folder from the production server and use git archive / CI/CD for clean deployments.

Moral of the Story

  1. Don't just see 403 and give up. Sometimes the fence is solid, but you can peek through the windows.
  2. The .git folder is a double-edged sword. Once it lives on a production server, disaster awaits.
  3. Rotate leaked database passwords. Right now.

Final Thoughts

I've reported this vulnerability following proper procedures. I didn't continue exploitation to the database because we're not here to cause damage.

But to my fellow developers managing web servers:

"Don't let your server become a .git museum."

If there's a .git folder on your production server — delete it! Or at least configure the blocking rules properly, not half-heartedly.

If you enjoyed this writeup, follow my Medium for more security stories that (hopefully) won't give you a headache.

Cheers, stay safe, and don't be the developer who forgets to delete .git 🫡