← All Status Codes
302
Found
↪️ Redirection Low Risk

📖 What Is HTTP 302?

The resource temporarily resides at a different URL. Unlike 301, search engines should keep the original URL. Browsers may change POST to GET on redirect.

🛡️ Security Implications

Same open redirect risk as 301. Also, POST-to-GET conversion can cause security issues if sensitive data was in the POST body.

🔍 Common Causes

Temporary redirect (login redirect, A/B testing, geolocation-based routing, maintenance page).

🔧 How to Fix

Use 307 instead of 302 if you need to preserve the HTTP method. Validate redirect URLs against a whitelist.

🖥️ How to Check

curl -I -o /dev/null -w "%{http_code}" https://example.com

🔗 Related Redirection Codes

301
Moved Permanently
303
See Other
304
Not Modified
307
Temporary Redirect
308
Permanent Redirect
📚 Learn Web Security — Free Course

HTTP 302 in depth — what you actually need to know

HTTP 302 Found (originally "Moved Temporarily") indicates the resource is temporarily at a different URL — clients should use the temporary URL for this request but continue using the original URL for future requests. The original URL is the canonical one; this is a temporary detour.

302 is the most-used redirect code in modern web applications because most frameworks default to it for things like post-login redirects, OAuth flows, and any "send the user somewhere after this action" pattern. The semantic meaning ("temporary") is often ignored by developers — many 302 redirects are actually permanent moves that should be 301. The wrong choice has SEO implications.

For SEO, 302 keeps the original URL in the search index and does not transfer ranking to the destination. This is correct for genuinely temporary redirects (maintenance pages, short-term campaigns) but wrong for permanent moves (use 301 instead). HTTP/1.1 also defines 307 (Temporary Redirect) which is more strictly defined than 302 — some applications prefer 307 for clarity.

Five real-world scenarios involving HTTP 302

POST/Redirect/GET pattern after form submission

After processing a POST request, redirect to a GET request for the result page (302 or 303). Prevents form re-submission on browser refresh. Standard web application pattern; the redirect itself is temporary (just for this submission flow), not a permanent URL change.

Login and OAuth flows

Login pages typically 302-redirect to a destination URL after successful authentication (returnUrl parameter or default landing page). OAuth flows have multiple 302 redirects between identity provider, application, and back. All temporary by nature — the URLs continue to exist for future logins.

Maintenance mode redirects

During scheduled maintenance, 302-redirect all requests to a maintenance page. Use 302 (temporary) so search engines do not de-index your URLs while maintenance is in progress. After maintenance, redirects are removed and original URLs return.

A/B testing redirects

Some A/B testing frameworks 302-redirect users to different variant URLs. Temporary by definition; the variants are alternatives being evaluated, not permanent URL changes.

Bug bounty — open redirects via 302

Same vulnerability class as 301 open redirects — applications taking URL parameters and 302-redirecting to them without validation enable phishing attacks. The status code (301 vs 302) does not matter for the attack; the lack of validation is the issue.

Common mistakes & edge cases

Using 302 for permanent URL changes (default behaviour of many frameworks)

Most web frameworks default to 302 for redirects. Developers using return redirect("/new-url") get 302 unless explicitly choosing 301. For permanent moves (URL restructuring, HTTPS migration, domain change), this loses SEO value.

Open redirect vulnerabilities in 302-redirect parameters

Same vulnerability class as with 301. Validate destinations against allowlist; do not redirect to arbitrary URLs from user input.

Long redirect chains involving 302s

Multiple temporary redirects in sequence cause performance issues and confuse search engines about canonical URL. Consolidate to single redirects.

Confusing 302 with 301 in monitoring

Monitoring tools track redirect ratios. Sudden shift from 200 to 302 might indicate a real issue (broken handler returning redirect) or might be intentional (new redirect added). Track redirect responses by intentional vs unintentional.

Using 302 when 303 or 307 is more semantically correct

303 See Other: forces GET on the redirect destination (specific to POST/Redirect/GET). 307 Temporary Redirect: preserves the original method (POST stays POST). 302 historically had ambiguous behaviour that 303 and 307 clarify. For new code, prefer 303 or 307 over 302 when the semantic difference matters.

Caching issues with 302 responses

302 responses are not cached by default (can be overridden with Cache-Control). If you have intermittent issues with stale 302 redirects, check for unexpected Cache-Control headers being added by intermediate caches or CDNs.

Frequently Asked Questions about HTTP 302

A redirect status code indicating the resource is temporarily at a different URL. Clients should use the temporary URL for this request but continue treating the original URL as canonical. Most common redirect status code in modern web applications.
301 = permanent move, search engines transfer rankings to new URL, browsers cache the redirect. 302 = temporary move, search engines keep old URL indexed, browsers do not cache long-term. Use 301 for permanent changes; 302 for temporary detours.
Genuinely temporary redirects: maintenance pages, A/B testing, post-form-submission redirects, login flows, OAuth flows. Anything where the original URL should remain the canonical one for future requests.
302 historically had ambiguous behaviour about whether the request method should change on redirect. 307 is more strictly defined: preserves the original method (POST stays POST). For modern code, 307 is preferred when the method should be preserved.
A redirect that explicitly forces the destination to be fetched with GET, regardless of original method. Specifically designed for the POST/Redirect/GET pattern (POST a form, redirect to GET the result). More semantically correct than 302 for that pattern.
Apache (.htaccess): Redirect 302 /old-page /new-page. Nginx: return 302 /new-page;. Code (PHP): header("Location: /new-page", true, 302); exit;. Most web frameworks default to 302 for the standard "redirect" action.
By default, 302s are not cached aggressively (unlike 301s). Cache-Control headers can override this. The non-caching default makes 302 safer for "we might change our mind" scenarios but means each request hits the redirect handler.
Yes — using 302 for what is actually a permanent move keeps the old URL indexed and does not transfer rankings to the new URL. Common mistake when frameworks default to 302 and developers do not change it for migrations. Use 301 for permanent moves.
Browser DevTools (Network tab): click any redirect request, see Status Code. Command line: curl -I -L https://example.com/path shows redirect chain with status codes for each hop. Online tools like httpstatus.io check redirect chains.
Yes — same vulnerability class as 301 open redirects. The status code does not matter for the attack; the lack of destination validation is the issue. Validate redirect destinations against allowlist regardless of which redirect type you use.