From 502d459babf666a29c635bcf962fb99cbfea59ce Mon Sep 17 00:00:00 2001 From: FAQ Bot Date: Wed, 21 Oct 2026 14:51:02 +0000 Subject: [PATCH] NEW: Why does a Playwright security test return HTTP 403 instead of the expec --- ...ght-403-vite-vs-404-nginx-security-test.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) create mode 100644 _questions/ai-dev-tools-zoomcamp/02-development/004_575d4af2e5_playwright-403-vite-vs-404-nginx-security-test.md diff --git a/_questions/ai-dev-tools-zoomcamp/02-development/004_575d4af2e5_playwright-403-vite-vs-404-nginx-security-test.md b/_questions/ai-dev-tools-zoomcamp/02-development/004_575d4af2e5_playwright-403-vite-vs-404-nginx-security-test.md new file mode 100644 index 00000000..2afe6af8 --- /dev/null +++ b/_questions/ai-dev-tools-zoomcamp/02-development/004_575d4af2e5_playwright-403-vite-vs-404-nginx-security-test.md @@ -0,0 +1,19 @@ +--- +id: 575d4af2e5 +question: Why does a Playwright security test return HTTP 403 instead of the expected + HTTP 404 when using Vite rather than production Nginx? +sort_order: 4 +--- + +When you run Playwright against the development frontend (Vite), you can get different HTTP status codes than in production (Nginx) because the request routing and security logic differ between environments. + +In the production setup, Nginx is configured to intercept access to private routes and return a `404` for blocked requests. In the Vite-based development setup, some requests are instead forwarded (e.g., via Vite dev proxy) to the API/backend. If the backend (or its auth/security middleware) blocks the request, it may return `403 Forbidden` because it’s making an authorization decision rather than pretending the route doesn’t exist. + +How to verify what’s happening: +- Compare the request flow in both environments (Dev: Vite/proxy → API; Prod: client → Nginx → (blocked/rewritten or passed to backend)). +- In Playwright, log the failing request URL and method, then check the backend logs (or middleware/auth logs) to see whether the backend is responsible for the `403`. +- Inspect your Nginx rules for private routes to confirm they rewrite/deny with `404`, and inspect your dev/proxy config to confirm which requests bypass Nginx. + +What to do: +- Update the test expectation to match the environment-appropriate behavior (often: `403` for authorization failures vs `404` when hiding private routes). +- Or make dev behavior consistent with prod by aligning the dev proxy/backend behavior with Nginx’s rule (e.g., translate `403` to `404` for the same private-route patterns, or ensure the dev stack uses the same blocking layer). \ No newline at end of file