QR Code Security: The "Quishing" Risks

QR codes are everywhere — menus, posters, packages, business cards. Their superpower is that they turn a physical thing into a URL you can tap. That same convenience is their weakness: a QR code hides the link, so the usual "hover to see where this goes" habit doesn't work. Attackers exploit exactly that, and it has a name: quishing — QR code phishing.

If you scan codes, or if you operate a platform that generates them, this matters. Here's what quishing looks like, how to check a code before you scan it, and what a responsible QR tool should do to protect users.

What quishing is

An attacker encodes a malicious URL in a QR code and gets you to scan it. Because your phone opens the destination automatically, a single scan can land you on a phishing page, a credential-stealing site, or a page that triggers a malicious download.

It works because QR codes bypass two natural defenses:

1. No hover preview. You can't inspect the link before you open it.
2. Physical trust. A sticker on a door, a poster, or a mailbox looks official, so people scan without thinking.

Common lures include fake payment screens, fake login pages, "install this update" prompts, and lookalike domains that differ from the real site by one character.

How to check a code before scanning

You can reduce the risk in a few seconds:

1. Use your phone's built-in camera scanner. Modern phones (iOS and most Android scanners) show the destination URL as a preview before opening it. Read it.
2. Verify the domain. The destination should be the site you expect. Look for typosquats: arnazon.com instead of amazon.com, or a domain that just differs by a character.
3. Prefer HTTPS and a recognisable domain. A code that opens to a page that looks right but is on an unrelated domain is a red flag.
4. Don't scan stickers over official codes. If a QR is stuck over another QR on a poster or a payment terminal, it may be an overlay attack. Be suspicious of codes that weren't printed as part of the original material.
5. Use a dedicated scanner with link preview if your OS doesn't preview — many QR apps show the URL and let you decide before opening.

The rule is simple: treat a scanned QR like an untrusted link you received out of the blue. If you wouldn't click it in a message, don't let a scan open it for you.

What happens after you scan

Even with caution, be aware of what the destination might try:

• Fake logins — the page looks like a sign-in for your bank, email, or a service. Real organisations don't put login forms on QR codes from unknown stickers.
• Fake update prompts — "Your device is out of date, tap to install." Real updates come from your OS, not a poster.
• Credential harvesting via lookalike domains — check the exact domain.
• Malicious downloads — especially on codes found in parking lots or taped to public fixtures.

If you've scanned and entered anything, change that password and enable 2FA. If you suspect a real attack on an organisation, report it to them and to any abuse channels.

What a responsible QR platform should do

If you run a service that generates QR codes — like a URL shortener with QR support — you have a duty to reduce abuse. The features that matter:

1. Destination scanning. Before creating a QR (or a short link), check the destination against known phishing/malware blocklists and flag or reject dangerous URLs.
2. Authentication for custom codes. Public, unauthenticated creation of custom aliases makes it trivial to mint abuse codes at scale. Requiring sign-in and applying rate limits slows abuse dramatically.
3. An abuse-reporting path. A clear way for users to report a malicious code, and a prompt takedown loop once reported.
4. Monitoring. Watch for bursts of new codes pointing to the same suspicious destination, which is the signature of a quishing campaign.
5. Transparent destination. When you create a QR, you should be able to see and change the destination; and the platform should show the resolved URL where users can verify it.

What this means for yas.sh

The platform already applies these protections: short links are validated to http/https, destination hosts are checked against private/metadata ranges, custom aliases require an account and are rate-limited, and there's an abuse-reporting path. QR codes reuse the same validated short-link destinations, so the QR itself can't be pointed at a javascript: payload or a private host. That's the baseline; active phishing-blocklist scanning is the next hardening step (see the roadmap).

The takeaway

QR codes are a genuinely useful technology, and quishing is a genuine risk — not a reason to avoid codes, but a reason to be deliberate. As a scanner, check the URL before opening and treat overlays with suspicion. As a platform operator, scan destinations, require authentication, offer abuse reporting, and monitor for campaigns. Do both and you get the convenience of QR without the blind trust.

The threat model of "quishing"

QR code phishing — "quishing" — works by exploiting the exact property that makes QR codes convenient: you cannot see the destination before you scan. An attacker encodes a malicious URL in a QR code and gets a victim to scan it, bypassing the habit of hovering over a link to check it before clicking. Because the code looks innocent and can be placed anywhere — a sticker on a poster, a fake sign, a slipped-in flyer — the victim scans and lands on a phishing page or a malicious download without the usual warning signals. Understanding this threat model is the first step to defending against it.

How the risk actually plays out

The risk is not that the QR technology is insecure; it is that scanning short-circuits the verification people normally do. When you click a link, you can hover, read the URL, and spot a suspicious domain; when you scan a QR, the action and the verification are often collapsed into one reflex. Attackers exploit this by placing malicious codes in physical spaces where trust is high — the gym notice board, the parking payment sign, the event poster. The code itself can also be a "malicious overlay" on a legitimate code, which is why placement and integrity matter as much as the code's content.

Defending yourself and your audience

Defense works at two levels. As a scanner, build a habit that restores verification: on most phones you can see the destination before it opens, or you can use a scanner that previews the URL — treat an unknown code like an unknown link, and never enter credentials or make a payment on a page you arrived at through an unexpected scan. As a publisher, protect your own codes by keeping the destination on a domain you control (a branded short link), printing or securing codes so they cannot be tampered with, and directing scans to a trackable, verifiable destination so any unusual traffic is visible.

The practical checklist

For a team, the checklist is short and repeatable: verify codes before trusting them, preview destinations on your devices, keep your published codes on domains you own and monitor them, and educate staff and customers that "scan then verify" is the safe default. Because quishing exploits a reflex, the defense is replacing that reflex with a quick verification step. The same caution you apply to links should apply to the codes you scan and the codes you print.