Restricting Access

Beyond passwords, Apache can allow or block requests based on where they're coming from -- by IP address, IP range, or hostname -- useful for admin panels, internal tools, or blocking known-bad traffic.

In this page:

Require ip
Combining Conditions
Blocking Instead of Allowing
IP Restriction Isn't a Complete Security Model

Require ip

Require ip 203.0.113.5 allows only that exact address; Require ip 192.168.1.0/24 allows an entire CIDR range, commonly used to restrict an internal tool to a company's office or VPN network.

Combining Conditions

<RequireAny> and <RequireAll> blocks combine multiple Require conditions with OR/AND logic. For example, wrapping Require ip 192.168.1.0/24 and Require valid-user in a <RequireAny> block allows access either from the office network *or* with valid login credentials -- useful for staff who need access both on-site and remotely.

Blocking Instead of Allowing

The same directives work in reverse for blocking: pairing Require all granted with a <RequireAll><Require not ip 203.0.113.5> condition denies just that one address while allowing everyone else -- useful for blocking a specific abusive IP without locking down the whole site.

IP Restriction Isn't a Complete Security Model

IP-based restriction is easy to bypass for a determined attacker (IP addresses can be spoofed for some attack types, and legitimate users behind a shared NAT/proxy can be blocked along with everyone else on that address). Treat it as one useful layer -- reducing exposed surface area -- not a substitute for authentication on anything genuinely sensitive.

Warning: Don't rely on IP restriction alone to protect something sensitive like an admin panel -- pair it with Basic Auth or application-level login wherever the content actually matters.

Example: Allowing office network OR authenticated users

apacheconf

<Directory "/var/www/example.com/internal">
    AuthType Basic
    AuthName "Internal Tools"
    AuthUserFile /etc/apache2/.htpasswd

    <RequireAny>
        Require ip 192.168.1.0/24
        Require valid-user
    </RequireAny>
</Directory>

{# Flagged by hand after confirming a runner can't handle this example (a shell command / go.mod file stored as a TopicExample, a language feature the configured runner version doesn't support, or output that blows a runner's sandbox limit) -- see TopicExample.norun. Never render the run button for these, regardless of language, since it would just fail at execute_code (or worse, hang the Judge0 queue on a submission that can never finish cleanly). #}

{# common_mistakes/chapter_summary/browser_support: on Hindi pages the view already swaps in the hi_ translation fields (or blanks these out if untranslated), so this renders correctly for both languages without a lang_code check here. #}

Common Mistakes

Relying on IP restriction as the only protection for something sensitive, when it's really just a coarse first layer, not real authentication.
Getting the RequireAny/RequireAll logic backwards, accidentally requiring both conditions to be true when only one should be enough (or vice versa).
Restricting by a home/office IP that changes (many residential ISPs assign dynamic addresses), silently locking yourself out the next time it changes.

🔒

Chapter Quiz — Complete all 4 topics to unlock

0/4 topics done

Complete these topics first:

← Previous Lesson SSL/TLS Setup Next Lesson → Security Headers