Meta refresh redirect is an HTML technique that automatically sends a browser to another page after a short delay or immediately. It uses a meta tag in the page header rather than an HTTP redirect, which makes it easy to create simple forwards, but also a common trick in spam, phishing pages, and tracking links.
How Meta Refresh Redirects Work
A meta refresh redirect is a client-side navigation instruction embedded in the page itself. Because the browser receives the redirect logic inside HTML rather than from the HTTP layer, it can fire immediately or after a short pause, which makes it simple but also less trustworthy than a server-side redirect.
That simplicity is why meta refresh is still encountered in legacy web pages, embedded content, and quick-and-dirty forwarding flows. It does not carry the same semantics as a proper HTTP 3xx response, so user agents, crawlers, and security tools may treat it differently.
Why It Is Risky for Users and Defenders
Meta refresh redirects are attractive to attackers because they can hide the destination behind a page that looks harmless long enough to build trust, then send the user onward. That pattern is common in phishing chains, spam landing pages, and tracking flows where the visible URL and the final destination are intentionally separated.
They also create review and detection blind spots, because the first page can appear low-risk while the second page hosts the real payload, credential harvest, or lure. In practice, the redirect itself is often not the abuse, it is the trust bridge that enables the abuse.
Where Meta Refresh Becomes a Web Security Problem
A meta refresh redirect becomes security-relevant when it is used to obscure destination control, bypass user scrutiny, or chain users through intermediate pages that defeat simple URL checking. It is especially problematic when security teams rely on the first URL alone, or when filtering and reputation systems inspect only the initial page and not the eventual target.
For defenders, the issue is less about the HTML tag itself and more about how it alters the path a user, scanner, or analyst perceives. That makes it a useful indicator in phishing infrastructure, open redirect abuse, affiliate tracking abuse, and other web flows designed to look routine while routing to something else.
Browser behavior can also vary by implementation details, timing, and content security context, so the same pattern may not be equally visible everywhere. That inconsistency is one reason it remains a nuisance in security review and incident investigation.
Safer Handling and Review Practices
When reviewing a page that uses meta refresh, validate both the apparent landing page and the eventual destination, and do not assume the first URL is the real endpoint. Security review should treat delayed client-side forwarding as a redirection mechanism that needs destination inspection, not just as cosmetic HTML.
For controlled environments, prefer server-side redirects where the destination is explicit in the response and easier to govern, log, and filter. If meta refresh must be used, keep the behavior predictable, avoid open-ended external jumps, and ensure the final destination is reviewed as part of the same content and trust decision.
Practitioner note: Meta refresh is often a compatibility shortcut, but from a security perspective it should be treated as a navigation control with real abuse potential, not as a harmless page decoration.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while OWASP ASVS sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1598 — Phishing for Information | Meta refresh is often used in phishing chains to move users from a lure page to a credential-harvest destination. |
| T1185 — Browser Session Hijacking | Client-side redirects can help steer victims toward pages that steal sessions or credentials after trust is established. | |
| Recommendation — Map redirect chains to phishing infrastructure and inspect the final destination in your detection workflow. Correlate redirect behaviour with session theft indicators and investigate follow-on credential abuse. | ||
| OWASP ASVS | V4 — API and Web Service | Redirect handling is a web application behaviour that should be validated to avoid unsafe navigation and trust confusion. |
| V16 — Security Logging and Error Handling | Redirect chains are easier to investigate when navigation and destination events are logged clearly. | |
| Recommendation — Verify redirect logic and destination handling as part of web-service security review. Log redirect creation and destination resolution so analysts can reconstruct user navigation paths. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Unsafe redirect behaviour is a common misconfiguration pattern when applications permit untrusted navigation paths. |
| Recommendation — Harden redirect handling so untrusted inputs cannot drive navigation to arbitrary destinations. | ||