Use an allow-list policy: deny access broadly with Require all denied, then add narrower <Directory> blocks with Require all granted only for directories that are meant to be public. In Apache, “root folder” can mean the server’s filesystem root (/) or a site’s configured DocumentRoot; choose the scope before changing the configuration.
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
For Apache HTTP Server 2.4, put filesystem authorization in the main server configuration or the relevant virtual host whenever possible. An .htaccess file can apply the same directory-level denial only when the server’s AllowOverride settings permit the authorization directives.
As an Amazon Associate I earn from qualifying purchases.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →First decide which “root” you need to protect
Apache administrators use “root folder” for two different filesystem locations. They have very different consequences when access is denied.
The server filesystem root: /
A block for <Directory "/"> establishes a server-wide default for filesystem content. It affects the entire filesystem tree that Apache could otherwise map to a request, including content used by virtual hosts. You then create explicit exceptions for every directory that should be served.
#1 Best Overall
This is the broadest policy. It minimizes the chance that a newly exposed directory becomes reachable by accident, but it requires a complete allow-list and careful review of every virtual host and published path.
A site’s DocumentRoot
A virtual host’s DocumentRoot is the directory from which that site serves files, such as /var/www/example/public. Restricting that exact path limits the policy’s blast radius to the site instead of changing the default for the whole server. Each virtual host can have its own DocumentRoot.
Before editing anything, read the active virtual-host definition and record the exact filesystem path. The path in a <Directory> block must literally match the path Apache uses; a URL such as /public is not a substitute for /var/www/example/public.
| Scope | Typical block | Effect | What you must maintain |
|---|---|---|---|
| Entire server filesystem | <Directory "/"> |
Denies by default across the filesystem tree | Explicit grants for every directory that any site must publish |
| One site’s document root | <Directory "/var/www/example/public"> |
Controls that site’s files and descendants | Grants for public subdirectories that are intentionally available |
The Apache 2.4 deny-by-default pattern
Apache’s recommended baseline is to deny access first and then grant only the locations that are intended for publication.
Server-wide filesystem policy
<Directory "/">
Require all denied
</Directory>
<Directory "/var/www/example/public">
Require all granted
</Directory>
Require all denied denies every request evaluated in that context. The narrower grant reopens only the site directory. Add additional grant blocks for other virtual hosts or shared public directories that must remain reachable.
Rank #2
DocumentRoot-only policy
If your goal is to protect one site rather than establish a server-wide default, keep the policy next to that virtual host:
Recommended Free Tools
DocumentRoot "/var/www/example/public"
<Directory "/var/www/example/public">
Require all denied
</Directory>
This configuration intentionally leaves the site unavailable until you add narrower grants for the files or subdirectories that should be public. For example:
<Directory "/var/www/example/public/assets">
Require all granted
</Directory>
<Directory "/var/www/example/public/index.html">
Require all granted
</Directory>
In practice, a web application normally grants its public directory and uses narrower denies for sensitive areas. The important rule is that every exception must name the real filesystem location and be deliberate.
Where to place the rule
| Location | Administrative access | Scope | Operational behavior | Important condition |
|---|---|---|---|---|
| Main server configuration | Required | Server-wide policy and shared defaults | Change the configuration, validate it, then reload Apache through the platform’s service manager | Best place for a global filesystem policy |
Relevant <VirtualHost> |
Required | One virtual host and its filesystem paths | Validate and reload after editing | Useful when different sites need different policies |
.htaccess |
Not required for the central configuration, but the directory must allow overrides | The directory containing the file and its descendants | Apache reads the file during request processing; no central-file edit is needed | AllowOverride must permit the authorization directive |
Main configuration or virtual host
Use the main configuration or the applicable <VirtualHost> block when you administer Apache. These contexts make the filesystem policy visible, allow a complete review of the merged configuration, and avoid depending on per-directory override permissions.
.htaccess fallback
In a directory that should never be served, an .htaccess file can contain:
Free tools Windows power users keep installed
One-click scans. No signup required.
Rank #3
Require all denied
Apache supports Require in both directory configuration and .htaccess contexts. However, an .htaccess file is ignored or rejected for directives that the enclosing configuration’s AllowOverride policy does not permit. If a request remains accessible, check the applicable AllowOverride setting before assuming the authorization rule is wrong.
How inheritance and matching affect the result
<Directory> covers descendants
A <Directory> section applies to the named filesystem directory and its descendants. A broad denial therefore reaches child directories until a more specific, applicable rule changes the result. Keep the hierarchy simple: establish the default at the highest required level, then add clearly named exceptions.
Protect a filename with <Files>
When the risk is a particular filename rather than an entire directory, use a <Files> section within the selected directory tree. This is useful for denying a sensitive file name wherever it appears under that tree, while leaving other public files available. The filename rule does not replace the directory policy; it is a narrower control layered on top of it.
Do not use <Location> for a filesystem object
<Location> addresses URL-space. It is not the correct container for protecting a filesystem directory or file. URL and filesystem sections can interact, and Apache warns that the combined, merged configuration determines the effective policy. If a <Directory> rule appears ineffective, inspect all applicable <Directory>, <Files>, <Location>, virtual-host, and override settings rather than adding another arbitrary deny.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Clear out junk files and repair common Windows errors3Fix the driver behind crashes, sound loss and screen glitchesDo not confuse hidden listings with access control
Options -Indexes prevents Apache from generating an automatic directory listing when no index file is available. It does not stop a client from requesting a known file directly. Use authorization directives such as Require all denied to block access; treat index suppression as a separate presentation and information-disclosure setting.
Rank #4
A safe implementation procedure
- Identify the effective site path. Locate the active virtual-host definition and confirm its
DocumentRoot. Write down the exact absolute filesystem path, including capitalization and any symlinked layout that the configuration actually uses. - Choose the policy scope. Select a server-wide
<Directory "/">default only when you are prepared to enumerate every directory that all virtual hosts must publish. Otherwise, target the individualDocumentRoot. - Place the deny rule in an authoritative context. Add the block to the main configuration or the relevant virtual host. If you must use
.htaccess, putRequire all deniedin the directory that needs protection and verify thatAllowOverridepermits it. - Add explicit grants. Create narrower
<Directory>blocks withRequire all grantedonly for directories that are intentionally public. Include every required virtual host when using a filesystem-root default. - Check for conflicting sections. Search the active configuration for broader or narrower
<Directory>,<Files>, and<Location>rules, as well as virtual-host-specific settings. Confirm that an.htaccessfile is not overriding the expected result. - Validate before reloading. Run the Apache configuration-test command supplied by your operating system or distribution. The exact command name differs by platform; do not reload an unvalidated edit.
- Reload through the service manager. Use the service-management procedure for the platform so Apache adopts the validated configuration without an unnecessary reboot.
- Test both outcomes. Request one deliberately allowed URL and one deliberately denied URL. Test a file in the protected directory directly, not only the directory URL, because disabling indexes does not prove that direct access is blocked.
- Read the error log if behavior differs. Authorization failures, path mismatches, and rejected
.htaccessdirectives are normally distinguishable in Apache’s error log. Use the message to identify the active context and correct the policy rather than weakening the denial.
Common failure modes and fixes
The browser returns an authorization error for the homepage
The deny rule is working, but no matching grant covers the requested path. Confirm the request’s file path, then add a narrower <Directory> grant for the intended public directory. Check that the grant’s path exactly matches the configured DocumentRoot.
A supposedly protected file is still reachable
Check whether the request is being handled by a different virtual host, whether a broader or more specific section changes the result, and whether a URL-space <Location> rule is interacting with the filesystem rule. Inspect the merged configuration and error log. Also verify that you placed the rule in the directory tree Apache is actually serving.
The .htaccess rule causes a server error
The enclosing configuration may not allow that directive in .htaccess. Review AllowOverride for the directory, move the rule into the main configuration or virtual host if you administer Apache, and validate before reloading.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Only directory listings disappeared
Options -Indexes affects automatic listings, not authorization. Add a Require all denied rule to the protected directory, then test a known filename directly.
One site works while another fails after a global change
A <Directory "/"> denial applies broadly. Compare each virtual host’s DocumentRoot with the explicit grant blocks and add an exception for every directory that should be public. If the sites need independent policies, move the rules into their respective virtual-host contexts instead of expanding a global allow-list.
Best Value
Choosing between filesystem-root and DocumentRoot protection
Use the filesystem-root pattern when the server is centrally managed and you want new filesystem locations to be private until explicitly published. It offers the smallest default exposure but creates the largest maintenance obligation: every public directory needs a grant.
Use a DocumentRoot-only block when you are securing one application, testing a site-specific change, or cannot safely alter unrelated virtual hosts. Its blast radius is smaller, and the configuration is easier to reason about, but other filesystem locations retain their existing policies.
Whichever scope you choose, keep the policy deny-first, document each exception, and review it whenever a virtual host or public directory is added.
Minimal reference configurations
Global deny with two public sites
<Directory "/">
Require all denied
</Directory>
<Directory "/var/www/example/public">
Require all granted
</Directory>
<Directory "/srv/www/another-site/web">
Require all granted
</Directory>
Every path not covered by an explicit grant remains denied by the global rule.
Private application data beneath a public site
<Directory "/var/www/example/public">
Require all granted
</Directory>
<Directory "/var/www/example/public/private">
Require all denied
</Directory>
The more specific directory policy protects the private subtree while the rest of the document root remains available. If a sensitive filename can occur in multiple public subdirectories, add an appropriate <Files> rule within the selected directory tree.
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.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →




