HTTP 403 Forbidden

Updated October 18, 2026Free mock REST & WebSocket APIs

HTTP 403 Forbidden — The server understood the request but refuses to authorize it.

Class: 4xx Client Error
Defined in: RFC 9110 §15.5.4
Official: Yes (IANA registry)
Cacheable by default: No (unless Cache-Control/Expires say so)
Safe to retry: Not without changing the request

Try it: get a real 403 response

Our test endpoint answers every request with 403 Forbidden.

curl -i https://mockfox.dev/api/status/403

Use it in tests, health-check monitors or to see how your client handles a 403. Add ?delay=2000 to slow it down.

What does HTTP 403 mean?

403 Forbidden means the server understood the request but refuses to fulfil it. Unlike 401, authenticating (again) won't help: either the user lacks permission, or access is blocked for everyone or for this client.

Servers may also answer 404 instead of 403 to avoid revealing that a protected resource exists.

When is 403 used?

A logged-in user requests something their role doesn't allow (another user's data, an admin page).
Directory listing is disabled and there's no index file (/images/).
A WAF, CDN or firewall rule blocks the request (country block, bot protection, suspicious payload).
File permissions on the server prevent the web server from reading the file.
Signed URLs (S3, CloudFront) that are expired or have a bad signature.

Common causes of a 403

Insufficient permissions for your account.
Your IP, country, VPN or user agent is blocked by a firewall or bot protection.
On Apache/nginx: wrong file ownership or permissions, missing index.html, or an .htaccess/deny rule.
On S3: the bucket policy or object ACL doesn't allow public reads (S3 returns 403 — not 404 — for missing objects when the requester can't list the bucket).

How to fix 403 Forbidden

If you're visiting the site

Check that you're signed in to the right account.
Turn off your VPN or proxy; some sites block VPN IP ranges.
Clear cookies and cache for the site, then retry.
If you believe you should have access, contact the site owner — you can't fix permissions yourself.

If you run the site or API (developers)

Return 403 for authenticated-but-not-allowed; 401 for not-authenticated.
Check file permissions: typically 644 for files and 755 for directories, owned by a user the web server can read as (www-data, nginx).
Look at your WAF/CDN event logs (Cloudflare Security Events, AWS WAF) to see which rule fired.
For S3/CloudFront 403s, verify the bucket policy, Origin Access Control and that the object key exists.

Returning or handling 403: server examples

nginx

location /internal/ {
    allow 10.0.0.0/8;
    deny all;            # everyone else gets 403
}

# Disable directory listings (403 when there's no index)
autoindex off;

Express

function requireRole(role) {
  return (req, res, next) =>
    req.user?.roles.includes(role)
      ? next()
      : res.status(403).json({ error: "forbidden", required: role });
}
app.delete("/api/users/:id", requireAuth, requireRole("admin"), deleteUser);

Next.js

// app/api/example/route.ts (Next.js App Router)
export async function DELETE(req: Request) {
  const user = await auth(req);
  if (!user) return Response.json({ error: "unauthorized" }, { status: 401 });
  if (!user.isAdmin) return Response.json({ error: "forbidden" }, { status: 403 });
  // ...
}

Example 403 response

HTTP/1.1 403 Forbidden
Content-Type: application/json; charset=utf-8

{"error":"forbidden","message":"You need the 'admin' role to delete users."}

Related status codes

Related tools

Frequently asked questions

How do I fix 403 Forbidden?

As a visitor: make sure you're logged in with the right account, disable your VPN, and clear the site's cookies. As the site owner: check file permissions, index files, access rules and firewall/WAF logs.

Is 403 Forbidden permanent?

Not necessarily. It lasts as long as the rule that causes it — a permission change, a firewall rule expiring or an IP unblock will lift it.

Why do I get 403 on an S3 file that doesn't exist?

If the requester lacks s3:ListBucket permission, S3 returns 403 Access Denied for missing keys instead of 404, so it doesn't reveal which objects exist.

403 or 404 for private resources?

Use 403 when it's fine to reveal the resource exists; use 404 when its existence itself is sensitive (e.g. a private repository).