Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitchesiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
The safest Apache 2.4 pattern is to deny access broadly, then explicitly grant access only to the directories that are meant to be public:
<Directory "/">
Require all denied
</Directory>
<Directory "/var/www/example/public">
Require all granted
</Directory>That example protects the entire server filesystem by default and reopens one website directory. However, “Apache root folder” can mean either the operating-system root directory (/) or a site’s configured DocumentRoot. Choose the correct scope before adding a rule: denying / affects every URL mapped to the server, while denying only a site’s DocumentRoot limits the change to that site.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minute
First clarify which “root folder” you mean
Apache maps requested URLs to files and directories on the server. Two different filesystem locations are commonly called the root folder:
The filesystem root: /
The path / is the top of a Unix-like operating system’s filesystem. A global rule for this path establishes a server-wide default: requests mapped anywhere under the filesystem are denied unless a more specific directory policy grants access.
#1 Best Overall
This is the broadest protection model. It is useful when you want an allow-list design in which nothing is web-accessible by default. It also means every site, virtual host, and explicitly published directory needs an appropriate grant.
The website’s DocumentRoot
A virtual host normally has a DocumentRoot, such as /var/www/example/public. This is the directory Apache uses as the filesystem base for that site’s URL space. A rule scoped to that exact path affects the site without changing unrelated virtual hosts or server directories.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →The DocumentRoot is configured in the main server configuration and can be different for each virtual host. Confirm the value in the virtual-host definition before writing a <Directory> block. A URL path and a filesystem path are not interchangeable: the block must contain the real path Apache uses on disk.
Choose the scope before writing a rule
| Policy scope | Example target | Effect | Allow-list work |
|---|---|---|---|
| Entire filesystem | / |
Denies access by default for all filesystem locations handled by Apache. | Every directory that must remain public needs an explicit grant. |
| One website | /var/www/example/public |
Changes authorization for that site’s document tree without imposing the same default on other sites. | Only that site’s public directories need grants; other virtual hosts keep their own policies. |
Use the filesystem-wide form when you administer the server and want a strict global baseline. Use the DocumentRoot-only form when you are changing one application, share hosting with other sites, or cannot safely predict which directories other virtual hosts require.
Apache 2.4 authorization directives
Apache HTTP Server 2.4 uses the authorization provider in mod_authz_core. The two directives needed for an allow-list are:
Require all deniedrejects every request evaluated in that context.Require all grantedallows every request evaluated in that context.
These directives replace the older 2.2-style access-control syntax in a current Apache 2.4 configuration. Put them in a context that corresponds to the object you are protecting.
Option 1: deny the entire filesystem, then grant public directories
Place the following in the main server configuration or in the relevant <VirtualHost> block:
Rank #2
<Directory "/">
Require all denied
</Directory>
<Directory "/var/www/example/public">
Require all granted
</Directory>The first block changes the default for the filesystem root. The second block is the exception for the site’s published files. Because a <Directory> section applies to the named directory and its descendants, files below /var/www/example/public are covered by that grant unless a more specific rule changes the result.
Grant additional sites explicitly
If the server hosts more than one website, add a block for each real public directory:
<Directory "/var/www/alpha/public">
Require all granted
</Directory>
<Directory "/srv/www/beta/site">
Require all granted
</Directory>Do not grant a parent directory merely because it contains a public child. A grant for /var/www, for example, is broader than a grant for /var/www/example/public and can expose other application files under that parent.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Option 2: restrict only a site’s DocumentRoot
When the policy should apply to one site rather than the whole server, scope the deny rule to that site’s exact document root:
DocumentRoot "/var/www/example/public"
<Directory "/var/www/example/public">
Require all denied
</Directory>Add narrower grants for the paths that should remain available. For example, if the application has a public subdirectory for static files, grant that child explicitly:
<Directory "/var/www/example/public/assets">
Require all granted
</Directory>This arrangement starts with a closed site tree and creates a deliberately small public surface. Make sure the DocumentRoot and every directory path in the authorization blocks use the same spelling, capitalization, and symlink-resolved location that Apache is configured to use.
Where to put the restriction
Main server configuration
The main configuration is the preferred location when you have administrative access. It can express a server-wide policy or a virtual-host-specific policy directly, and it keeps filesystem authorization visible to the administrator responsible for the server.
Use a global <Directory "/"> block for a server-wide baseline, or put the relevant <Directory> blocks inside the appropriate <VirtualHost> definition when the policy belongs to one site.
.htaccess
An .htaccess file can provide the same directory-level authorization effect when Apache’s AllowOverride setting permits the required authorization directives. In a directory that must never be served, the file can contain:
Require all deniedThis file applies to the directory in which it is placed and the request processing beneath that directory. It is useful when a site administrator cannot edit the main configuration, but it is not an escape from server policy: if AllowOverride does not permit the directive, Apache will reject or ignore the attempted override according to its configuration and the request will not behave as intended.
Because .htaccess files are read during request processing, central configuration is generally easier to audit and manage. Use the main configuration whenever you control it; use .htaccess only where the server’s override policy explicitly allows the authorization directive.
Main configuration versus .htaccess
| Decision point | Main configuration or virtual host | .htaccess |
|---|---|---|
| Administrative access | Requires permission to edit Apache’s server or virtual-host configuration. | Can be used by a directory administrator when the server permits the needed override. |
| Scope | Can cover the whole server, one virtual host, or selected filesystem directories. | Acts from the directory where the file is installed and its descendants. |
| Override dependency | Does not depend on AllowOverride for the rule itself. |
Works only if AllowOverride enables the authorization directive. |
| Operational workflow | Validate the complete Apache configuration, then reload Apache through the platform’s service manager. | Changes are picked up during requests, but invalid or disallowed directives can produce configuration errors; server policy still controls what is permitted. |
| Best use | Central, auditable security policy. | Directory-specific control when central access is unavailable. |
Do not use the wrong container
Use <Directory> for filesystem paths
<Directory> matches an actual filesystem directory and its descendants. That makes it the natural container for restricting the root filesystem, a virtual host’s document root, or a private subdirectory.
Use <Files> for a sensitive filename
<Files> can deny a particular filename anywhere within a selected directory tree. For example, a sensitive configuration file can be blocked independently of the directory’s general policy:
<Directory "/var/www/example/public">
Require all granted
<Files ".env">
Require all denied
</Files>
</Directory>The directory remains public, while requests for the named file are denied. Keep the filename rule as narrow as possible and verify that the filename matches the files actually present.
Do not substitute <Location> for a filesystem rule
<Location> operates in URL space, not directly on a filesystem object. It is therefore not the right primary container for protecting a directory on disk. Apache also warns that <Location> and <Directory> sections can interact; an apparently correct rule may be changed by another section in the merged configuration. When behavior differs from the policy you wrote, inspect all applicable containers rather than adding increasingly broad exceptions.
Why Options -Indexes is not enough
Disabling directory indexes prevents Apache from generating an automatic listing when a directory has no index document:
Options -IndexesThat setting controls listings only. It does not authorize or deny direct requests for known filenames. A user who knows a file’s URL may still request it unless an authorization rule such as Require all denied blocks access. Use index suppression as a separate hardening measure, never as a replacement for the directory access policy.
Step-by-step implementation checklist
- Identify the real filesystem target. Read the active virtual-host definition and confirm its
DocumentRoot. Decide whether the policy belongs to/or only to that document root. - Choose the configuration context. Prefer the main server configuration or the relevant
<VirtualHost>. If you cannot edit those files, check thatAllowOverridepermits authorization directives before using.htaccess. - Add the deny rule. Use
<Directory "/">for a server-wide default, or the exact document-root path for a site-specific default. PutRequire all deniedinside the block. - Add explicit grants. Create
<Directory>blocks withRequire all grantedonly for directories that are intentionally public. Use the narrowest paths that meet the application’s needs. - Review file-specific protections. If a sensitive filename must remain inaccessible inside an otherwise public tree, add a nested
<Files>denial for that filename. - Check for conflicting sections. Search the complete active configuration for other
<Directory>,<Files>,<Location>, and.htaccessrules that may affect the same request. - Validate before reloading. Run the Apache configuration-test command supplied by your operating system or hosting platform. The exact command differs by distribution; do not skip this check.
- Reload Apache. Use the platform’s service manager to reload the server after the configuration test succeeds. A reload applies the policy without treating an untested configuration as production-ready.
- Test both sides of the policy. Request one deliberately public URL and one URL that should be denied. Confirm that the public resource is served and the restricted resource receives an authorization failure.
- Inspect the error log if results differ. Authorization messages, an incorrect path, a disallowed
.htaccessdirective, or a conflicting section usually identifies why the observed result does not match the intended rule.
How to verify that the path and policy match
Check the path, not just the URL
A request such as /images/logo.svg is evaluated against the filesystem path produced by the virtual host’s URL-to-file mapping. The authorization block must match that filesystem path. A block for /var/www/example does not automatically protect or grant a different directory such as /srv/www/example, even if both are associated with similarly named URLs.
Test an allowed directory
Select a file that is intentionally public and request it through the correct virtual host. This confirms that the grant matches the active document root and that the server can still serve the required content.
Test a denied directory
Select a file below the denied scope that has no narrower grant. Request it directly rather than relying on a directory listing. The result should be an authorization failure, and the error log should show the access decision if logging is configured to record it.
Test the virtual host you actually changed
When multiple virtual hosts share one server, make sure the test request reaches the intended host. A request handled by another virtual host can appear to ignore a correct rule simply because a different DocumentRoot and configuration were selected.
Best Value
Troubleshooting an ineffective restriction
The rule produces a configuration error
Confirm that the directive is valid in its context and that the Apache installation supports the 2.4 authorization form. If the rule is in .htaccess, verify that AllowOverride enables the required authorization directives. Move the rule to the main configuration when you administer the server and need a guaranteed central context.
Public files are unexpectedly denied
Check the exact path in the grant. The <Directory> argument must literally match the filesystem directory Apache uses. Also check whether the global deny was added without a corresponding grant for this site, or whether a more specific denial applies to the requested child directory or filename.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Private files are still reachable
Look for an overly broad grant on a parent directory, a child-specific Require all granted, or a URL-space rule that changes the result. Review the merged configuration and the request’s actual virtual host. Do not assume that hiding directory indexes removed the file’s URL; direct access still requires authorization.
A change appears to have no effect
Verify that Apache was reloaded after editing the main configuration, that the configuration test succeeded, and that the request reached the server instance and virtual host you changed. For .htaccess, confirm the file is in the directory you intended and that overrides are enabled for that path.
Practical policy patterns
Server-wide closed by default
<Directory "/">
Require all denied
</Directory>
<Directory "/var/www/example/public">
Require all granted
</Directory>
<Directory "/var/www/another-site/public">
Require all granted
</Directory>This is an allow-list for a multi-site server. Any newly added site remains inaccessible until its intended public directory receives a grant.
One site closed by default
DocumentRoot "/var/www/example/public"
<Directory "/var/www/example/public">
Require all denied
</Directory>
<Directory "/var/www/example/public/assets">
Require all granted
</Directory>This pattern is appropriate when other virtual hosts have separate policies and you want to minimize the blast radius of the change.
Free tools Windows power users keep installed
One-click scans. No signup required.
A directory that must never be served
For a directory beneath an otherwise public tree, place an .htaccess file containing:
Require all deniedUse this only where the server’s AllowOverride policy permits it. A central <Directory> block is preferable when available because the rule is visible alongside the rest of the server’s filesystem policy.
Key decisions before you deploy
- Scope: Decide whether the target is the operating-system root
/or one site’sDocumentRoot. - Default: Start with
Require all deniedand add grants only for publication directories. - Path accuracy: Match the literal filesystem paths used by Apache, not merely the URL paths shown in a browser.
- Configuration location: Prefer the main configuration or virtual host; use
.htaccessonly whenAllowOverridepermits the directive. - Container choice: Use
<Directory>for filesystem directories,<Files>for specific filenames, and do not rely on<Location>to protect a disk path. - Indexing: Treat
Options -Indexesas listing control, not access control. - Operations: Test the configuration, reload through the platform’s service manager, then verify both an allowed and a denied request.
For Apache 2.4, the durable security model is simple: deny the filesystem scope you control, grant only the exact directories intended for publication, and verify the merged configuration that Apache actually applies.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Recommended Free Tools
