“Quishing” — phishing through QR codes — earns headlines because the attack is theatrical: a sticker over a parking meter, a fake invoice in an inbox. The theatre hides a useful structure. There are exactly two attacks, they live in different worlds, and each has a defence that works and several that only reassure.
Attack one: the sticker
Someone prints their own code and pastes it over yours. No system was hacked — paper was. That's why no software fully solves it: the defence is physical and procedural. Print codes into artwork rather than as applied labels where you can; make walking your own sites' codes part of routine (a scan of your own poster takes four seconds); and give scanners a reason to notice tampering — which is where the printed URL earns its keep. A code on your own domain reads as yours; a sticker carrying a stranger's shortener over it is visibly foreign to anyone who glances.
Attack two: the repoint
The subtler attack targets dynamic codes at the destination end: a link that was clean when created goes bad later — a compromised landing page, an expired domain re-registered by someone else, or an abuser who deliberately passes a creation-time check and repoints afterwards. The key insight: a destination checked once is not a destination that stays checked. Repointing is the product; any defence that only runs at creation is decoration.
The defence that works is continuous: here, every destination is screened against Google Safe Browsing when written and re-walked nightly, every night, for every live code. A hit switches that one code off within minutes — one code, not the customer's whole estate — and because the block flows through the same edge-published state as any repoint, it reaches every printed copy at once. An attacker can wait out a create-time check; they cannot wait out tonight.
What the scanner-side advice is worth
Most published guidance addresses the person scanning — preview the URL, distrust stickers, don't enter credentials after a scan from a wall. All true, all worth repeating to your staff, and all outside your control as a code's owner. The ownable defences are the ones above, plus two structural choices:
- Separate what you host from what customers author. Our hosted landing pages serve from an entirely separate domain from the one printed codes resolve through, so no page anyone publishes can taint the domain your codes share — the reasoning is on the landing-pages feature page.
- Refuse dangerous payload types outright. A destination that isn't plain http(s) — script schemes, data URIs — is refused at write and at serve time, because rows written before a rule are still rows.
- Prefer a vendor who publishes their security posture. Ours is on the security page, including what we don't claim.
The un-glamorous summary
Sticker attacks are beaten by print design, inspection habits and a recognisable domain. Repoint attacks are beaten by continuous destination screening and per-code kill switches. Everything else — logos, colour, “secure QR” badges — is branding, not defence. If you're evaluating platforms, ask each one precisely when destinations are re-checked after creation; the vendor questions worth asking are on record with our answers, and this one separates the category fast.