---
title: 403 Forbidden: causes and how to fix it
description: A 403 means the server understood you perfectly — and is refusing anyway. Here's what causes 'Forbidden', how it differs from 401, and how to track down the fix.
canonical: https://watchfor.io/blog/403-forbidden
---

# 403 Forbidden: causes and how to fix it

2026-03-10 · WatchFor Team · Networking · http, debugging, basics

A 403 means the server understood you perfectly — and is refusing anyway. Here's what causes 'Forbidden', how it differs from 401, and how to track down the fix.

You request a page and the server slams the door: **403 Forbidden.** It's one of the more frustrating errors, because it's not "I don't understand" or "I'm broken" — it's "I understand exactly what you want, and the answer is *no*."

## What a 403 means

A **403** is a [client error](/blog/http-status-codes-explained): the server received and understood the request, but **refuses to authorise it**. You're not allowed, full stop. Importantly, retrying the same request the same way won't help — the refusal is deliberate.

## The usual causes

| Cause | What's happening |
| --- | --- |
| **Missing permissions** | Your account/role isn't allowed to access this |
| **File/directory permissions** | The server can't (or won't) serve the file |
| **No directory index** | A folder with no index file and listing disabled |
| **IP / geo blocking** | Your IP or region is on a blocklist |
| **WAF / security rule** | A [firewall](/blog/waf-explained) flagged the request as suspicious |
| **Hotlink protection** | Assets blocked when requested from another site |
| **Expired/invalid auth** | A token that's present but not accepted |

## 401 vs 403 — the key distinction

People constantly mix these up. The difference is about *identity*:

- **[401 Unauthorized](/blog/401-vs-403)** → "I don't know who you are. **Log in.**"
- **403 Forbidden** → "I know who you are, and you **still** can't have this."

401 is solved by authenticating; 403 means authentication won't help — you lack permission.

## How to fix it

1. **Check permissions first.** For an app, is the user's role allowed here? For files, are the filesystem permissions correct?
2. **Look for a missing index** if it's a directory URL.
3. **Check security layers.** A [WAF](/blog/waf-explained), rate-limiter, or IP/geo block can return 403 for legitimate traffic — including monitoring tools and bots you *want*.
4. **Verify auth tokens.** A token that's expired or scoped wrong can read as forbidden.
5. **Read the server logs.** They usually say *why* the 403 was returned — the fastest path to the cause.

> **A monitoring gotcha:** if your checks hit a protected endpoint, a **403 may be the *expected* response** — so configure your monitor to treat it as healthy there, and only alert on a 403 where you'd expect a 200.

## The bottom line

| | In one line |
| --- | --- |
| **What** | The server understood you and refuses — you're not allowed. |
| **vs 401** | 401 = "log in"; 403 = "logging in won't help." |
| **Where to look** | Permissions, security rules, IP/geo blocks, logs. |
| **Monitoring** | A 403 can be the *expected* result on protected paths. |

A 403 is a permission problem, not a breakage. Check who's allowed, what's blocking, and the logs — and remember that "logging in" is the fix for 401, not 403.

Related: [401 vs 403](/blog/401-vs-403) and [HTTP status codes explained](/blog/http-status-codes-explained).

---

Canonical page: https://watchfor.io/blog/403-forbidden · All articles: https://watchfor.io/blog/all.md · Site guide: https://watchfor.io/llms.txt