Vulnerabilities
.htaccess vs web.config on a Public Origin
April 6, 2024
.htaccess vs web.config on a public origin is Apache per-directory config versus IIS/ASP.NET config sitting in the document root. Both are meant for the server, not for browsers. If GET /.htaccess or /web.config returns the file, you donated rewrite maps, directory rules, and sometimes connection strings or module lists. Static hosts and CDNs that treat every path as a public object are how this happens. RoastMyOpsec does not currently score /.htaccess or /web.config. It does probe other well-known leftovers (.env, .git/HEAD, dump.sql). Deny these names at the edge anyway. It does not parse config files or use them as an exploit recipe.
The practical difference
Apache reads .htaccess when AllowOverride is on. IIS reads web.config. Nginx does not use .htaccess; a copied file is still a public object if the origin serves it. The leak is the text, not which server you run.
Cousins: web.config.bak, .htaccess.bak, applicationHost.config souvenirs in zip backups. See dump.sql vs backup.zip.
How to choose a deny list
CI: fail if .htaccess or web.config appear in a static artifact that is not supposed to configure a server (Jamstack dist/). CDN: deny those basenames even on Apache origins so a mis-set MIME type cannot serve them as text/plain. If you need the file for the origin, keep it off the public bucket.
| File | Typical stack | What a GET can show | Takeaway |
|---|---|---|---|
| /.htaccess | Apache | Rewrites, denies, sometimes auth hints | Deny at CDN; not a scored roast path |
| /web.config | IIS / ASP.NET | Modules, sometimes connection strings | Same class; strip from static buckets |
| /.env | Any | Live secrets | Incident; roast does probe this |
| robots.txt Disallow | Crawlers | Names, not the file bytes | Not access control |
What the roast can prove
A 404 on /.htaccess is not proof it is gone under /blog/.htaccess. Edge deny is cheap. Pair with directory listing if autoindex would have shown the name, and with phpinfo if a PHP dump named the config path.
Common mistakes
The first mistake is uploading the Apache tree to S3 including .htaccess.
The second mistake is gitignoring .env and committing web.config with a password.
The third mistake is Disallow: /.htaccess and calling it a fix.
Free audit the URL you own
RoastMyOpsec is a defensive public-surface roast: headers, cookies, sensitive paths, and more — no exploit payloads. Start with the free audit, then open the vault if the blurred findings look expensive.
Free audit nowFAQ
- Is a downloadable .htaccess a vulnerability?
- It is an information leak. Remove it from public objects. If it contained secrets, rotate them.
- Does RoastMyOpsec fetch .htaccess or web.config?
- Not as scored paths today. Deny the names anyway. The scan does probe other well-known leftovers.
- Do I need .htaccess on a CDN-only site?
- Usually no. Origin rules belong in the CDN or the real server config, not as a public file.
Sources
Related guides
Vulnerabilities
Exposed .git vs .env on Production WebsitesVulnerabilities
Directory Listing vs 403 for Backup and Static FoldersVulnerabilities
robots.txt Disallow vs Access Control for Hidden Paths