# How to Check a Website for Open Redirects

Canonical: https://vulnify.app/blog/how-to-check-website-open-redirects

Test redirect parameters with Vulnify’s Open Redirect Checker. Read a confirmed finding, a bounded pass, and what to fix before you retest.

A login page that accepts a next or return parameter will happily send someone to whatever address that parameter names, if the application never checks the destination. That is an open redirect. What an open redirect is , and why phishing kits like it, is already explained on the tool page. This article is the check: how to test a site you operate, how to read a hit, and how to read a pass that is narrower than it looks. When a redirect parameter is worth testing Look for any URL your own site builds from a query string after login, logout, a checkout return, a marketing link, or an OAuth callback. If a visitor can change that value and land on a different host, the parameter is doing too much. Editing one parameter in the browser shows you one URL. It does not tell you whether a second parameter on the same page, or a redirect field inside a form, behaves the same way. The Open Redirect Checker walks a bounded set of those parameters and reports what it actually observed. Run a Quick check Open the checker and paste the page that accepts the redirect. A login or logout URL on a host you control is the right target. Use a full URL, the same shape as the field placeholder. Leave Mode on Quick for the first run. Quick does not need an account. The Stack menu sits beside it: Generic, Nginx, Apache, Cloudflare, Express, Joomla, Next.js, or WordPress. Pick the stack you actually run if you want the remediation lines phrased for that server. The stack does not change which probes run. The button reads Run Quick Check. The checker sends bounded probes toward example.com . It does not publish a list of bypass strings, and this article will not either. What Quick does and what it skips Quick stops early once a redirect is confirmed. The probe set stops at four confirmed results. It does not submit forms. If the risky redirect lives on a form, including a POST form, Quick can miss it. That is what Comprehensive is for, after you sign in. Read the result The page returns a letter grade, findings with a severity, and remediation lines with a priority and an action. Two outcomes matter. A confirmed redirect A confirmed probe is titled “Unvalidated redirect parameter behavior detected.” Severity is high. The grade is D when at least one redirect is confirmed. If more than one probe is confirmed, a second finding appears: “Multiple redirect parameters appear abusable,” severity medium. The remediation is practical. Allow only same-origin relative paths, or an explicit host allowlist. Reject protocol-relative and external URLs. Prefer a fixed route after login, and an opaque state token, instead of trusting a destination the visitor supplied. A bounded pass A pass is titled “No open redirect behavior observed in bounded probe set.” Severity is info. The grade is A when nothing was confirmed. Read the title literally. The checker did not observe the behavior in the probes it sent. The product text says that absence does not prove the site is immune. A parameter it did not try, or a form Quick did not submit, can still be open. Change the application, then retest Fix the destination check in the application, deploy it to the same host you tested, and run Quick again. You want the bounded-pass title, not a quieter version of the high finding. If the site has several login entry points, test each URL. One fixed page does not fix the others. Redirect chains after a domain or HTTPS move are a different job. Use the redirect chain check , and the article on how to audit redirect chains after a migration , when the question is “where does this host end up,” not “can a parameter leave the host.” When to sign in for Comprehensive Comprehensive is labeled sign-in required until you have an account. Choosing it while signed out sends you to register and brings you back. Once you are signed in, Comprehensive can submit discovered forms that contain a redirect field, and it can use POST when that is the form’s method. Run it when Quick was clean and you still suspect a form, or when Quick already confirmed a problem and you want the form paths included before you call the work done. A full website vulnerability scan is a separate product and spends scan credits. Use it when you want a broader pass, not as a substitute for fixing the redirect. Three places people actually find this A staging login that still carries next from an old framework is the usual one. The developer pastes the staging login URL, leaves Quick selected, and runs it. A confirmed finding means the parameter left the host during the probe. The ticket is not “research open redirects.” The ticket is “stop accepting a destination we did not choose,” with the remediation lines from the result attached. A shop that changed checkout often has a logout link that was copied from the theme. Same check, different URL. Run it against the logout URL, not against the homepage. The homepage rarely contains the parameter. The logout URL does. The third case is a form. Quick comes back with the bounded-pass title, and the team is about to close the ticket. The redirect they worry about is a hidden field on a POST form the theme submits after login. Quick never submitted that form. Sign in, switch Mode to Comprehensive, and run the same URL again. Comprehensive can submit discovered forms that contain a redirect field, and it uses POST when that is the form’s method. A pass on Quick plus a hit on Comprehensive is a successful test, not a contradiction. What to change, in the order that holds First, stop reflecting the visitor’s destination. Send people to a fixed path after login. If the product genuinely needs a return path, allow only a relative path on the same origin, or a host that is on a list you wrote. Reject protocol-relative URLs. They look relative and they are not. Reject anything with a scheme you did not expect. An opaque state token is the other pattern the remediation names. The application stores the destination in its own session and puts a random token in the URL. The visitor can change the token and get nothing useful. They cannot paste a different host into it. Deploy that change to the host you tested. Run Quick again on the same URL. If the high finding is still there, the deploy did not reach that host, or a second parameter is still open. The medium finding, “Multiple redirect parameters appear abusable,” is how you notice the second one. Fix both before you call the retest clean. What this check does not prove It does not test every parameter on the site. It does not replace a review of your OAuth client’s allowlist. A grade of A means the bounded probe set did not observe an unvalidated redirect. Ship the fix, retest the same URL, and keep the result with the ticket.