Solutional
We help the Estonian retailer Coop maintain and develop its e-commerce site. In August 2020, we were asked to fix a security issue reported by security engineer Ando Roots, who also published a detailed analysis of the vulnerability.
The Open Redirect Vulnerability
The issue allowed an attacker to create a link that could redirect a Coop customer to a malicious website after login. The fake site could imitate Coop's login page, display an error such as “Invalid username or password”, and trick the customer into entering their credentials again.
Vulnerabilities like this remain common because frameworks cannot protect developers from every unsafe assumption. User-controlled input must always be treated as untrusted, especially when it affects navigation, authentication, or access control. We put on our white hats and investigated the flow from an attacker's perspective.
How the Redirect Parameter Worked
The Coop login page accepted a GET query parameter named next. Its purpose was legitimate: after signing in, a customer could return to the page they originally wanted to visit instead of being sent to a generic landing page.
For example, this URL redirected the user to their shopping lists after a successful login.
The problem was that the redirect value was not sufficiently restricted. An attacker could provide a URL pointing to an external domain. After logging in successfully, the customer would be sent to a site controlled by the attacker.
A convincing fake page could then ask the customer to sign in again. After capturing the credentials, the attacker could redirect the customer back to Coop, where the existing session would still appear normal. The victim might never realize that their username and password had been exposed.
How We Fixed the Open Redirect
The solution was to validate the redirect target before using it. The exact implementation depends on the application, but we chose an allowlist approach: redirects are permitted only to routes explicitly defined by the application. Any other value is rejected with an error.
An allowlist is safer than a blocklist because it defines the small set of known, valid destinations rather than trying to anticipate every malicious variation. The implementation differs between projects, so we have not included a generic code sample; Ando's article contains additional technical detail.
Security Lessons for Web Developers
Security is often underestimated until an incident occurs. In this case, an external researcher responsibly reported the issue instead of exploiting it, and the vulnerability was ultimately fixed.
The broader lesson is simple: never trust user input. Validate redirect targets, URLs, identifiers, permissions, and any other data that can influence application behavior. Thinking like an attacker during development is one of the most effective ways to find weaknesses before someone else does.
