> ## Documentation Index
> Fetch the complete documentation index at: https://docs.safesquid.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Access Restriction

# Build precise web access decisions

## Problem statement

Broad allow rules create malware, abuse, and data-loss exposure. Blanket deny rules break legitimate work. Enterprise web policy must decide with more context than IP address alone: who the user is, what application is involved, where traffic is going, when it is happening, and what content is moving.

## Client scenario

Use Access Restriction when you need to:

* allow or block by user, group, destination, category, or application
* apply stricter controls during business hours or for regulated teams
* combine identity, HTTPS visibility, and profiling into one enforcement path
* prove why a request was allowed, denied, or redirected

## Key benefits

SafeSquid access restriction ties enforcement to the rest of the platform:

* [Authentication](/Authentication) provides identity and group context
* [SSL Inspection](/SSL_Inspection) provides visibility into encrypted traffic
* profiling engines provide request, response, category, time, and application context
* logs and reporting provide evidence for investigation and audit

That makes policy more precise and easier to defend operationally.

## Prerequisites

### Client-side preparations

* Route client traffic through SafeSquid.
* If policy must apply to HTTPS traffic, deploy the Root CA and enable HTTPS inspection.

### SafeSquid-side setup

* Confirm identity integration if you want user- or group-based policy.
* Define the profiles and categories the access policy will consume.
* Decide your rule order before deployment because top-down policy order affects outcome directly.

## Setup instructions

### Build policy inputs first

Before writing restriction rules, define the signals they will consume:

* authenticated users and groups
* request profiles
* response profiles
* categories
* time or business context

This avoids building access rules that look complete but match nothing useful.

### Create ordered restriction entries

In the Configuration Portal, create access-restriction entries from most specific to most general.

Put business exceptions and critical-deny rules above broad defaults. If a broad rule sits too high, later rules never get a chance to apply.

### Keep the action model explicit

For each restriction entry, document whether it should:

* allow
* deny
* redirect
* apply additional inspection or restriction profiles

Operators should be able to explain the intended outcome without reverse-engineering the entire rule stack.

### Test by realistic user path

Do not validate only with anonymous traffic. Test with the actual user, group, device path, and destination type the rule is meant to govern.

## Verification and validation

### Positive tests

Use at least one test for each intended decision path:

* a user or group that should be allowed
* a user or group that should be denied
* a destination or category that should be blocked
* an application or profile that should trigger special handling

Expected result:

* the rule order produces the intended action
* the applied profiles and filter path are visible in logs
* the user sees the expected allow, deny, or redirect behavior

### Negative tests

Test a nearby but legitimate workflow that should stay allowed.

Expected result:

* the broader restriction rule does not break approved business activity
* exception logic does not leak into unintended users

## Troubleshooting guide

### A rule exists but never seems to apply

Likely causes:

* a higher rule matches first
* the required identity or profile signal is missing
* HTTPS traffic is not being decrypted

Isolation steps:

* review rule order
* confirm authentication and profile assignment
* confirm whether the traffic is visible to SafeSquid

Remediation:

* move the rule higher if appropriate
* fix the missing prerequisite signal
* retest with the same user and destination

### Too much traffic is blocked

Likely causes:

* a broad deny rule sits above a needed exception
* category or profile conditions are too wide

Isolation steps:

* identify the exact rule that triggered
* compare affected users against intended scope

Remediation:

* narrow the matching conditions
* place the approved exception above the broad deny
* retest both blocked and allowed paths

### Policy works for HTTP but not HTTPS

Likely causes:

* HTTPS inspection is not enabled
* bypass logic excludes the traffic from inspection

Isolation steps:

* confirm the request path is decrypted
* inspect whether request or bypass profiles are modifying the flow

Remediation:

* enable the required HTTPS inspection path
* remove or narrow the bypass condition

## Related controls / next steps

* Use [Request Profiles](/Request_Profiles) and [Response Profiles](/Response_Profiles) to classify traffic before enforcing policy.
* Use [Web Categorization](/Web_Categorization) to refine destination-based decisions.
* Use [Security Logs](/Security_Logs) and [Reporting Module](/Reporting_Module) to prove which rule triggered.


## Related topics

- [Access Restriction](/use_cases/access_restriction/access_restriction.md)
- [Access restrictions](/admin_guide/infrastructure_and_access/access_restrictions.md)
- [Working of Default Entries in Access Restrictions](/use_cases/access_restriction/working_of_default_entries_in_access_restrictions.md)
- [Access Profiles](/admin_guide/policies_and_profiles/access_profiles.md)
- [Access the Interface](/getting_started/access_the_interface.md)