How to Validate QR Destinations Without Creating Open Redirect Vulnerabilities

For developers building dynamic QR systems, the challenge is not simply generating a scannable code. It is controlling what happens when someone scans it, especially when the destination can be changed without replacing the printed code.

One poorly designed redirect endpoint can turn a useful QR feature into an open redirect vulnerability.

The Problem With Unrestricted Redirects

Consider a redirect endpoint that accepts a destination through a query parameter:

https://qr.example.com/redirect?url=https://example.com

https://qr.example.com/redirect?url=https://example.com

If the server redirects to whatever URL the request supplies, an attacker could replace the destination with a phishing website.

The initial link still uses the familiar QR domain, which may make the malicious destination appear more trustworthy.

The underlying problem is straightforward: the application trusts user-controlled input when deciding where to redirect a visitor.

1. Use Destination IDs Instead of Arbitrary URLs

A safer design separates the QR code's identifier from its destination.

Instead of passing the complete URL in every request, use a unique identifier:

https://qr.example.com/redirect?id=campaign_123

https://qr.example.com/redirect?id=campaign_123

The server looks up the corresponding destination in its database and redirects the visitor according to the application's security policy.

This approach offers two advantages:

• The destination cannot be changed simply by editing the scan URL.
• Destination changes can be managed through a controlled process.

However, destination IDs are not a complete security solution. The application must still validate saved destinations, enforce permissions on updates, and prevent unauthorised users from modifying the mapping.

2. Validate URLs Before Saving Them

If users can configure QR destinations, validate the URL when it is created or updated.

A reliable validation process should:

• Parse the URL using a standard URL parser.
• Allow only supported schemes, typically HTTPS.
• Check the hostname against an explicit allowlist when the application restricts destinations.
• Reject embedded credentials and unexpected ports when they aren't required.
• Enforce path restrictions if only specific endpoints are permitted.

Avoid checking URLs with simple string matching.

For example, a URL beginning with https://trusted.example could actually point to [https://trusted.example.attacker.test](https://trusted.example.attacker.test.).

The text looks familiar, but the hostname is different.

Validation should operate on parsed URL components, not assumptions about how a string looks.

3. Choose a Policy That Fits Your QR System

Not every QR platform has the same requirements.

For internal workflows, restricting redirects to approved routes is usually the simplest option.

For partner campaigns, an allowlist of approved domains can provide stronger control.

For platforms that support arbitrary external destinations, a fixed allowlist may not be practical. In that case, validate URL structure, restrict dangerous schemes, control who can update destinations, and consider displaying the full external destination before redirecting users.

Remember that HTTPS does not guarantee that a website is trustworthy. It protects the connection, not the visitor from malicious content.

A destination that was valid yesterday may no longer meet your security policy today.

Dynamic QR systems should validate destinations during both creation and modification. They should also enforce access controls, maintain audit records of important changes, and define how invalid or reported destinations are handled.

At scan time, the redirect service should resolve the stored destination and apply the relevant security checks before issuing the redirect.

If those checks fail, return a safe error page rather than redirecting to an unverified destination.

5. Test the Redirect Logic Before Deployment

Testing only a valid destination is not enough. The redirect endpoint should also be tested against malformed inputs and attempts to bypass the validation rules.

Also test unusual ports, embedded credentials, encoded input and hostname variations. Confirm that the validation logic and the redirect framework interpret the destination consistently.

The Takeaway

Dynamic QR codes separate the printed code from the destination it resolves to. That flexibility is useful, but it introduces a security responsibility.

A secure implementation should avoid accepting arbitrary redirect URLs when a server-side destination mapping will work, validate destinations when they are saved, enforce permissions on changes, and apply the appropriate policy before redirecting visitors.

For developers working on QR infrastructure, destination validation is not just an input-handling detail. It is part of protecting the trust users place in the system.

How would you handle external destinations in a dynamic QR platform: restrict them to an allowlist, or allow arbitrary URLs with additional safeguards?

10 Proven Strategies to Grow Your Business, How QR Codes Are Used Today, Common QR Code Mistakes to Avoid for Better Scan Performance

Originally published at https://digitalqr.hashnode.dev on October 10, 2026.