Keep Require all denied on the root directory

The fixapache2.conf / httpd.conf

<Directory />
    Options None
    AllowOverride None
    Require all denied
</Directory>

<Directory /var/www/html>
    Options -Indexes +FollowSymLinks
    AllowOverride None
    Require all granted
</Directory>

This is Apache’s shipped default. On most servers the correct action here is to put it back.

Directives on this page

Require

Grants or denies access to a container. Apache ships Require all denied on the root directory, so the shipped default is closed and the finding is almost always that someone opened it.

• acceptsall denied | all granted | not <entity> | <provider> <args>
• valid indirectory, .htaccess

httpd.apache.org 2.4 mod_authz_core docs

If you see this

AH00526: Syntax error on line 14 of /etc/apache2/apache2.conf: Argument for 'Require all' must be 'granted' or 'denied'

Require all takes exactly one of two words. Typos land here, and so does reaching for the 2.2 vocabulary — there is no `Require all deny`. — apache/httpd modules/aaa/mod_authz_core.c

AH00526: Syntax error on line 14 of /etc/apache2/apache2.conf: Unknown Authz provider: valid-user

The word after Require is not a registered provider, which almost always means the module supplying it is not loaded. valid-user comes from mod_authz_user and ip comes from mod_authz_host; neither is implied by mod_authz_core. — apache/httpd modules/aaa/mod_authz_core.c

AH01630: client denied by server configuration: /var/www/html/private

The runtime counterpart, logged each time a rule refuses a request. Seeing this is the control working — it is only a problem when the path surprises you, which is the usual sign that a broad Require all denied is shadowing a narrower grant. — apache/httpd modules/aaa/mod_authz_core.c

Why it matters

The <Directory /> block sets the policy for the filesystem root, and Apache applies directory sections from shortest path to longest — so / is the base that everything else overrides.

Denying at / and granting back at /var/www/html means the default answer for any path Apache is asked about is no. A path bug, an Alias typo, a rewrite mistake, a symlink pointing somewhere unexpected — all of them hit a wall, because nothing outside your document root was ever permitted.

Reverse it, and every one of those becomes file disclosure.

This is not hypothetical

In October 2021, Apache 2.4.49 shipped a path normalisation change that allowed .. sequences through URL decoding — CVE-2021-41773. The fix in 2.4.50 missed double URL encoding, so CVE-2021-42013 followed days later. Both were exploited in the wild within hours of disclosure.

The detail that matters here: both required a non-default configuration. The traversal only reached files that Apache was willing to serve, and a server with the default Require all denied on <Directory /> was not willing to serve anything outside its document root. Servers that had swapped it for Require all granted had their /etc/passwd read — and with mod_cgi loaded, had commands executed.

So the population that got hit was, specifically, the people who had removed a default they didn’t understand.

Full details are on the path traversal page.

Why people remove it

The same way trust gets into pg_hba.conf: something returns 403, and this makes it stop.

<Directory />
    Require all granted        # don't
</Directory>

The real fix is almost always a <Directory> block for the specific path you wanted to serve. If content lives outside /var/www, grant that directory — not the root of the filesystem.

Options None in the root block matters too: it means no Indexes, no ExecCGI, and no FollowSymLinks by default. Symlink following at / is its own route out of the document root.

Verify it worked

Check what the running server has, not what one file says:

sudo apachectl -t -D DUMP_INCLUDES
sudo grep -rA4 '<Directory />' /etc/apache2/ /etc/httpd/ 2>/dev/null | grep -iE 'Require|Options|AllowOverride'

Expect Require all denied. Require all granted under <Directory /> is the finding, and it is the single most dangerous line in an Apache config.

Then prove the deny is real — ask for something well outside the document root:

curl -si 'http://localhost/../../../../etc/passwd' | head -1
curl -si --path-as-is 'http://localhost/cgi-bin/.%2e/.%2e/.%2e/etc/passwd' | head -1

Expect 403 Forbidden or 404, never 200 with file contents.

Find any other place the root has been re-granted:

sudo grep -rn 'Require all granted' /etc/apache2/ /etc/httpd/ 2>/dev/null

Every result should name a specific document root. Any that names /, or sits inside a <Directory /> block, is the problem.

Before you apply this

Putting Require all denied back on a server that has been running without it will 403 anything served from outside a granted directory — and on a long-running server, that’s often more than you’d think.

Find out what’s actually being served from where before you change it:

sudo apachectl -S
sudo grep -rhE '^\s*(DocumentRoot|Alias|ScriptAlias|DocumentRoot)' /etc/apache2/ /etc/httpd/ 2>/dev/null

Every path in that output needs its own <Directory> block with Require all granted. The common ones people miss:

• An Alias /media /srv/uploads with no matching <Directory /srv/uploads>.
• A vhost whose DocumentRoot is under /home or /opt.
• ScriptAlias /cgi-bin/ pointing somewhere outside /var/www.

Stage it: add the specific <Directory> grants first, reload, confirm the site works, and only then tighten <Directory /> back to denied. Both states are safe individually; the broken one is denying the root before granting the leaves.

apachectl -t will not catch this — the config is syntactically fine. The failure is a 403 on a real page, so check the site, not just the parser.

Related

• The Apache path traversal — what this default prevented.
• Disable unused modules — mod_cgi is what turned it into RCE.