How to Protect the htaccess File

Your .htaccess file often holds sensitive configuration: rewrite rules, access controls, references to password files, and directory locations. Serving it as plain text to anyone who requests https://yourdomain.com/.htaccess hands an attacker a map of your site's defences. This guide explains how .htaccess protection actually works on Noiz hosting, how to confirm your file is not publicly readable, how to add an explicit rule correctly, and how to extend the same protection to the sensitive files Apache does not cover for you.

Last reviewed: 27 July 2026, against Apache HTTP Server 2.4 (current stable series). This guide is written for Noiz hosting and is kept current against Apache. It complements, and does not replace, the official Apache documentation linked below.

Official Documentation Reference

• Apache HTTP Server: .htaccess files (how-to)
• Apache core: the <Files> directive
• Apache core: the <FilesMatch> directive
• Apache mod_authz_core: the Require directive
• Apache: upgrading 2.2 access control to 2.4

Prerequisites

• Access to your website's files, through your hosting control panel's File Manager or over SFTP/FTP.
• A site served by Apache. The .htaccess file is read only by Apache, so none of this applies to a site served purely by Nginx. If you are unsure which applies to your account, open a support ticket and the Noiz team will confirm.
• A copy of your existing .htaccess file. One typo in this file can take an entire site offline with a 500 Internal Server Error, so back it up before you edit.

The Short Answer: Apache Already Protects It

On modern Apache (version 2.4, which is what Noiz hosting runs), access to .htaccess is denied by default. The standard server configuration ships with a rule equivalent to the following, applied globally so that no client can read any file whose name begins with .ht:

<Files ".ht*">
    Require all denied
</Files>

Some Apache packages write the same rule as <FilesMatch "^\.ht">. Either form does the same job, and because it is set in the main server configuration, an .htaccess file cannot override it. In the vast majority of cases you therefore do not need to add anything to your own .htaccess at all. The best first step is not to add a rule, but to confirm the protection is working.

Confirm Your .htaccess Is Not Publicly Readable

Request the file directly and look at the status code rather than the page, because some browsers silently download the file instead of displaying it:

curl -I https://yourdomain.com/.htaccess

Replace yourdomain.com with your own domain. What the response means:

• 403 Forbidden: the file is protected. This is the expected result on Noiz hosting, and it means Apache is refusing to serve the file.
• 404 Not Found: either there is no .htaccess file in that folder, or the server is hiding its existence outright. Both are safe.
• 200 OK: the server is willing to serve the file. That is unusual on Noiz hosting, and the explicit rule below closes the gap.

If you would rather not use a shell, opening https://yourdomain.com/.htaccess in a browser works too. A 403 page is the pass; the file downloading or displaying as text is the fail.

Adding an Explicit Rule (Defence in Depth)

If you want the protection written into your own .htaccess rather than relying solely on the server default, add the block below to the .htaccess file at your document root, usually httpdocs or public_html depending on your hosting plan. It costs nothing, it documents the intent, and it travels with the site if you ever move it to a host that is less careful.

# Deny web access to .htaccess and .htpasswd
<Files ".ht*">
    Require all denied
</Files>

Save the file. The change takes effect on the next request, and there is nothing to restart.

Do not paste the deny directives on their own. A bare Require all denied (or the legacy Deny from all) with no <Files> wrapper applies to the entire directory, not just the .htaccess file, and returns 403 for every page and asset in that folder and everything below it. The <Files ".ht*"> wrapper is what limits the rule to the files you actually want to hide.

If You See Older Apache 2.2 Syntax

Guides written for Apache 2.2, including earlier versions of this article, use a different and now-deprecated set of directives. They are worth recognising, because they turn up constantly in copy-and-paste hardening snippets:

<Files ~ "^\.ht">
    Order allow,deny
    Deny from all
    Satisfy all
</Files>

Three points matter here.

1. The argument to Order is a single token with no space after the comma. Order allow,deny is valid; order allow, deny is a syntax error that Apache rejects, and it will take the site down with a 500 error until you remove it. This one typo is behind a large share of "my site broke after editing .htaccess" tickets.
2. The <Files> wrapper is not decorative. Strip it away and correct the comma, and the block becomes valid but denies the whole folder rather than one file, producing a site-wide 403. The snippet only ever made sense inside a container.
3. The directives are obsolete. On Apache 2.4, Order, Deny, Allow and Satisfy survive only through the legacy mod_access_compat module, and mixing them with the modern Require style in the same file gives results that are hard to predict. Satisfy all in particular achieves nothing useful here. Prefer the 2.4 block above for anything you write today.

Protect the Files Apache Does Not Cover

This is where the real exposure usually sits. Apache shields .ht* files by default and nothing else, so everything below is served happily to anyone who guesses the URL. If you only make one change after reading this guide, make it this one.

Dot-Prefixed Files

A single rule covers .env, .gitignore, .user.ini, .DS_Store and anything else beginning with a dot:

# Refuse to serve any file whose name starts with a dot
<FilesMatch "^\.">
    Require all denied
</FilesMatch>

.env is the one that matters most. Laravel, Symfony and many other frameworks keep database passwords and API keys in it, and automated scanners request /.env on every site they touch as a matter of routine.

Gotcha worth knowing: this rule does not interfere with SSL certificate renewal. <FilesMatch> tests the filename only, not the folder path, and the validation files placed in /.well-known/acme-challenge/ have ordinary names. A rule that blocked the /.well-known/ directory would break renewals, so do not convert this into a path-based block without testing.

Backups, Database Dumps and Editor Leftovers

Files such as index.php.bak, database.sql or config.php.old are served as plain text, because Apache only hands a file to PHP when the name ends in .php. A database dump sitting in your document root is a complete copy of your site's data, available to anyone who asks for it by name.

# Refuse to serve backups, dumps, logs and editor leftovers
<FilesMatch "\.(bak|old|orig|save|swp|swo|sql|log|sh|inc)$">
    Require all denied
</FilesMatch>

Treat this as a safety net rather than a solution. Move backups and database dumps out of the document root entirely, so they are never reachable over the web in the first place.

WordPress Configuration

On a WordPress site, add:

<Files "wp-config.php">
    Require all denied
</Files>

Under normal conditions PHP executes wp-config.php and the visitor sees nothing, so this rule can look redundant. It exists for the abnormal condition: if the PHP handler fails after an update or a configuration change, Apache falls back to serving the file as plain text and your database credentials go out over the wire. It is cheap insurance against a bad five minutes.

A Deployed .git Folder

If your site was put live with git clone or git pull, the .git folder came with it, and it holds your complete source history. A <FilesMatch> rule will not help, because the exposed items are files inside a dot-prefixed folder rather than dot-prefixed files themselves. Block the path instead:

RedirectMatch 404 ^/\.git(/|$)

Returning 404 Not Found rather than 403 Forbidden is deliberate. A 403 confirms there is something there worth protecting, while a 404 gives a scanner nothing to work with. Better still, do not deploy the .git folder to a live site at all.

Check the File Permissions Too

Apache rules govern who can fetch the file over the web. Filesystem permissions govern who can read or change it on the server, and that is a separate question. Set .htaccess to 644, which lets the owner read and write it while everyone else may only read it:

chmod 644 .htaccess

You can set the same value from your File Manager's permissions dialog if you prefer. Never set .htaccess to 777. A world-writable configuration file lets any compromised script on the server rewrite your access rules and inject redirects, which is a favourite trick of malware that targets shared hosting.

Confirm It Is Working

Test each protected path and read the status line. A 403 or 404 is a pass; a 200 is a fail:

curl -I https://yourdomain.com/.htaccess
curl -I https://yourdomain.com/.env
curl -I https://yourdomain.com/wp-config.php
curl -I https://yourdomain.com/.git/config

Then load your home page and click through a few pages, including anything that submits a form or loads content in the background. If something returns a 403 that should not, one of the rules is broader than you intended, so remove the blocks one at a time until you find it.

Troubleshooting

Symptom: the whole site or folder returns 403 after editing .htaccess. You almost certainly pasted Require all denied or Deny from all without the <Files> wrapper, so the deny applies to the entire directory. Wrap the directives in <Files ".ht*"> ... </Files> and reload.

Symptom: .htaccess still downloads as text. The default protection is not being applied. Add the explicit <Files> block above. If it still serves, contact Noiz support so the server configuration can be checked.

Symptom: a 500 Internal Server Error appears after saving. There is a syntax error in the file, commonly the stray space in order allow, deny, an unclosed </Files> or </FilesMatch> tag, or a missing quotation mark. Restore your backup to confirm, then re-add the rules one at a time.

Symptom: the error log says a directive is "not allowed here". AllowOverride is restricted for that folder, so Apache will not accept these containers from an .htaccess file. Open a support ticket and the Noiz team will apply the rule at server level for you.

Symptom: nothing changes at all. Confirm the file is named exactly .htaccess, with the leading dot and no hidden .txt extension, and that it sits in the folder you intend to protect rather than its parent. Enable Show hidden files (dotfiles) in your File Manager if you cannot see it. If the site is served by Nginx, .htaccess is ignored entirely.

Symptom: SSL certificate renewal starts failing. Check that no rule blocks the /.well-known/ path. The <FilesMatch "^\."> rule above is safe, but a path-based block on dot-prefixed folders is not.

Related htaccess Guides

• How to Disable Directory Browsing Using the htaccess Rule
• How to Block Any IP Address via an htaccess Rule
• How to Restrict Access to Directories by IP Address

Need a Hand?

You can edit .htaccess from your hosting control panel's File Manager or over SFTP. If you are unsure whether your file is protected, or an .htaccess change has taken a site offline and you need it reversed quickly, open a support ticket from your Noiz client area and the team will assist. On a managed plan, hardening of this kind is handled for you as standard.