QR Code Security: Best Practices (2026 Guide)
A practical, expert-reviewed playbook to stop QR phishing (quishing), protect your customers, and keep your brand trustworthy.
Last updated: 2026-08-19
Author: [Your Name], CISSP, CIPP/E — Senior Security Strategist and Search Quality Expert
Meta description (summary for humans and AI): Learn how QR codes work, how quishing attacks trick users, and the exact steps consumers and businesses should take to prevent fraud. Includes checklists, developer hardening guidance, incident response templates, and compliance tips.
Key Takeaways
- A QR code is a container. The risk is almost always the destination or action it triggers (URL, Wi‑Fi join, app deep link, payment form), not the pixels themselves.
- Quishing swaps or overlays malicious codes to route you to spoofed sites that steal credentials or payments.
- For consumers: inspect the physical code, preview the URL, confirm HTTPS and the domain, avoid sideloaded apps, and turn on MFA or passkeys.
- For businesses: brand your codes and context, use owned or branded domains, harden redirects, and publish what users should expect.
- Build detection and response: inventory all codes, monitor scans, rotate or expire where appropriate, and post clear incident notices if tampering occurs.
TL;DR: QR codes are safe when you control the destination and verify it before taking action.
Contents
- What is quishing?
- How QR codes work (and what they cannot do)
- Consumer best practices (step by step)
- Business and developer best practices
- Detect, monitor, and respond to tampering
- Accessibility, privacy, and compliance
- Real‑world scenarios and red flags
- Developer hardening checklist
- FAQs
- Glossary
- References
Quick answer: What is quishing?
Quishing is phishing delivered via a QR code. Attackers place or overlay a fake code in a trusted physical context such as a parking meter, restaurant tent, EV charger, poster, conference badge, or parcel label. When scanned, it sends you to a spoofed site that looks real but captures passwords or payments, or it tries to trick your device into unsafe actions such as installing an app from outside official stores.
Why it works: people trust the physical context and tap through without scrutinizing the URL or the app store source.
How QR Codes Work (and What They Cannot Do)
- What they are: QR codes encode text. Most often that text is a URL, but it can also be a Wi‑Fi configuration (SSID and password), a vCard contact, a payment deep link, an SMS draft, or a phone number.
- What they cannot do: A static image cannot execute code by itself. Risk appears when your device follows the encoded instruction and you confirm an action without verification.
- Static vs dynamic
- Static: Encoded content never changes, for example a direct URL to
https://example.com/menu. Static is reliable when printed and verified, but hard to update if content changes.
- Dynamic: The code points to a short link or redirect you control, for example
https://qr.example.com/x7ab3. You can update destinations, apply security, add analytics, set expirations, or switch to a warning page if tampering is suspected. Flexibility increases, so security must increase too.
- OS behavior and deep links
- Most smartphone cameras show a preview link. Tapping opens your default browser, or an app via deep link (iOS Universal Links, Android App Links, intent URIs). Always review prompts before approving.
- Wi‑Fi join codes and device settings prompts require explicit user consent on modern OS versions. Treat them like any other trust decision.
Consumer Best Practices (Step by Step)
Stay skeptical of the destination, not the dots.
- Inspect the physical code
- Look and feel: run a finger across printed codes. If you feel a sticker lip or see a misaligned overlay, do not scan.
- Check placement and branding: off‑brand colors, pixelated art, odd locations, or codes covering original print are red flags.
- Preview the URL before you tap
- Use the camera preview to read the full domain. Does it exactly match the brand you expect? Watch for typos and extra words, for example
pay-parking-city-xyz.com instead of the city’s official domain.
- Be cautious with unfamiliar link shorteners and random subdomains. When unsure, type the official address into your browser or use the organization’s app you already have installed.
- Confirm HTTPS and site identity
- Proceed only if the site loads with HTTPS and no browser security warnings.
- Tap the address bar lock or site info to view details. If your password manager does not offer to fill, pause and confirm the domain.
- Do not download apps from QR codes
- Decline prompts to install apps from outside official stores. On Android, never accept APK downloads from a QR code. On iOS, do not trust enterprise provisioning prompts unless you are within your employer’s documented process.
- If a code claims you need an app, search the store by the brand name yourself.
- Never enter passwords or payments on unfamiliar domains
- For parking, utilities, deliveries, or fines, confirm the website on the organization’s main site or verified social account. When in doubt, pay through the official app you already use.
- Turn on MFA or passkeys
- Enable MFA for email, social, and banking. Prefer phishing‑resistant options such as passkeys (FIDO2/WebAuthn) or security keys.
- Avoid auto‑actions
- Do not auto‑join Wi‑Fi or allow device config changes unless you fully trust the source and context. For sensitive work, use cellular or a trusted VPN.
- Trust context more than design polish
- Logos and sleek pages can be faked. If the timing or request feels off, verify with staff or the organization via a known channel.
- Report suspicious codes
- Tell the venue, city authority, or event organizer when you see possible tampering. Do not remove stickers yourself; let staff handle it safely.
- Keep your device current
- Update your OS and browser. Turn on built‑in safe browsing and phishing protection. Use a password manager.
Consumer 10‑second scan checklist:
- Physical check: looks original, not a sticker overlay
- URL preview: exact brand domain expected
- HTTPS lock: no warnings
- No sideload prompts
- No passwords or payments on unfamiliar domains
Business and Developer Best Practices
Your reputation rides on every scan. Secure the destination, set clear expectations, and watch for tampering.
- Brand your codes and the surrounding context
- Use your logo, brand colors, and a consistent frame design. Add microcopy near the code, for example: This QR goes to
yoursite.com/menu. We never ask for payment here.
- Provide a short, human‑readable fallback URL, for example
yoursite.com/menu, so users can type it.
- Use owned or branded domains
- Host dynamic redirects on your primary domain or a branded subdomain you control, for example
qr.yoursite.com.
- Avoid generic public shorteners that are commonly abused; unfamiliar domains reduce trust and conversions.
- Harden redirects and links
- Enforce HTTPS and preload HSTS for QR domains.
- Remove open redirects. Only allow destinations that match strict allowlisted paths or hosts.
- Use signed, expiring tokens for campaign links. Bind tokens to context when possible, such as location or time window.
- Disable indexing of redirect endpoints with
X‑Robots‑Tag: noindex and robots.txt to reduce discovery by attackers.
Example NGINX allowlist for a QR redirector (no open redirects):
server {
listen 443 ssl http2;
server_name qr.yoursite.com;
# Strict transport security
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
# Content Security Policy for landing pages
add_header Content-Security-Policy "default-src 'self'; frame-ancestors 'none'; base-uri 'self'";
# Allowlist mapping
map $arg_c $dest {
default "";
# Map short codes to known internal paths only
x7ab3 /menu;
ev24 /charging/pay;
}
location /go {
if ($dest = "") { return 410; }
return 302 https://www.yoursite.com$dest;
}
}
- Control the physical environment
- Use tamper‑evident media: embossed or laminated labels, microtext, holograms, or recessed mounts that are hard to cover.
- Print on textured or curved surfaces that resist overlays where feasible.
- Document inspection schedules for high‑traffic assets such as kiosks, EV chargers, and retail signage.
- Govern your QR inventory
- Maintain a registry: where each code is placed, owner, purpose, destination, creation date, and change history.
- Rotate or expire event‑based codes; validate content before reuse.
- Log scans and management actions. Collect only what you need and define a retention period.
- Protect payments and accounts
- Do not build do‑it‑yourself card collection. Use a PCI DSS v4.0 compliant gateway with hosted fields or redirect flows.
- Display clear cues that reassure users: consistent domain, recognizable payment provider, and expected 3‑D Secure flows.
- Offer phishing‑resistant sign‑in such as passkeys. Fall back to OTP only when necessary and rate limit attempts.
- Secure app deep links
- Implement iOS Universal Links and Android App Links so legitimate scans route into your official app rather than random browsers or counterfeit apps.
- For deep links that perform sensitive actions, require an authenticated session inside the app, not merely the presence of the app.
- Set strong web defenses on QR landing pages
- Use modern headers: HSTS, CSP, Referrer‑Policy, Permissions‑Policy, and X‑Content‑Type‑Options.
- Require HTTPS with TLS 1.2+ and modern ciphers. Monitor for certificate misissuance with Certificate Transparency.
- Implement rate limiting, bot filtering, and WAF rules focused on credential stuffing and card testing.
- Prevent open redirect and parameter abuse
- Never accept an arbitrary
url or next parameter without strict validation. Normalize, verify against an allowlist, and reject anything external.
- Publish what users should expect
- On the sign or page near each code, tell people where it goes and what it will never ask for. Example: Scan to view our menu at
yoursite.com/menu. We never collect payment here. For payments, use our app or pay at the register.
- Build quishing awareness into staff training
- Teach frontline teams to spot overlays and handle reports. Provide a rapid channel to security for removal and takedown.
- Test before you print
- Include QR destinations in QA and security testing. Validate links on both iOS and Android, in multiple browsers, and in low‑signal conditions.
Detect, Monitor, and Respond to Tampering
A fast, clear response limits harm and preserves trust.
Detection and monitoring
- Baseline normal scan patterns: time of day, geographies, and asset locations. Alert on spikes or out‑of‑region scans.
- Track error rates and bounce patterns; sudden increases can indicate tampering.
- Monitor brand and domain misuse with DMARC, TLS certificate transparency, Safe Browsing, and typosquat watchlists.
- Encourage user reports with a short URL or QR pointing to a report form, and add a phone number for urgent cases.
Incident response playbook
- Contain
- Immediately redirect dynamic codes to a neutral warning landing page if you suspect tampering. Example message: We detected possible QR tampering at this location. Please navigate to
yoursite.com manually or ask staff for help.
- If a physical overlay is present, disable the affected asset and post a temporary notice.
- Assess
- Check logs for time window, approximate number of scans, and any observed form submissions.
- Identify whether credentials or payment attempts occurred and whether data reached your systems or a third party.
- Eradicate
- Remove malicious overlays with documented procedures and gloves; photograph for evidence.
- Reprint or relocate codes with tamper‑evident materials. Patch any web weaknesses discovered.
- Notify
- Post a clear incident notice on your site and relevant social channels. Offer steps for users to verify accounts, reset passwords, or dispute charges.
- If payment data may have been exposed, engage your payment processor and follow PCI DSS incident requirements.
- Where required, notify regulators or affected users under applicable laws such as GDPR or state breach statutes.
- Recover and improve
- Rotate tokens, shorten expirations, and tighten allowlists.
- Update training, SOPs, and preventive controls. Capture lessons learned.
Sample short public notice copy
- We are investigating possible QR code tampering affecting [location or asset] between [dates]. If you scanned a code at this site and entered any information, please visit
yoursite.com/security for guidance. We do not collect payments via table QR codes. You can always type yoursite.com directly into your browser. We will share updates here.
Accessibility, Privacy, and Compliance
Accessibility (WCAG 2.2 AA)
- Always provide a human‑readable fallback URL adjacent to the code.
- Use sufficient color contrast and a readable label explaining the destination and action.
- Offer non‑camera alternatives for users with visual or motor impairments, such as NFC tap or typed URL.
Privacy by design
- Minimize data in scan analytics. Avoid precise GPS; coarse location or asset ID often suffices.
- Provide a privacy notice near first use that explains what scan data you collect and why.
- Respect regional laws such as GDPR and CCPA. Conduct a DPIA if scan analytics combine identifiers.
- Define retention and deletion schedules for scan logs. Secure logs with access controls and encryption at rest.
Compliance touchpoints
- PCI DSS v4.0 for any payment flows.
- SOC 2 and ISO 27001 for organizational controls where relevant.
- NIST SP 800‑63 for authentication assurance; prefer phishing‑resistant factors (passkeys).
- Follow platform guidelines for Apple App Store and Google Play policies when your code routes to apps.
Real‑World Scenarios and Red Flags
Parking meters
- Safe pattern: a code that loads your city domain with HTTPS and offers payment via a known gateway.
- Red flags: newly placed sticker, odd domain, countdown timers forcing immediate payment.
- What to do: confirm
city.gov or the utility’s known domain, or pay via the official city app.
Restaurant menus and orders
- Safe pattern: menu or ordering on the restaurant’s domain or a known platform such as a widely recognized delivery provider.
- Red flags: unexpected account creation, request for card data on a sketchy domain, push to install an app from outside official stores.
- What to do: ask staff, or type the restaurant name into maps or search and navigate from there.
EV chargers and kiosks
- Safe pattern: branded domain or app deep link to the official provider; clear signage that matches the app you already use.
- Red flags: peeling label, generic short domain, device asking for updates or APK downloads.
- What to do: use the provider’s app directly or the card reader; report suspicious codes to site ops.
Package delivery and returns
- Safe pattern: tracking pages on the carrier’s domain and return labels generated within your account.
- Red flags: codes on doorknob tags directing you to pay redelivery fees; SMS drafts after scanning that ask you to send codes.
- What to do: sign in to the carrier app you already have installed or use the number on the official receipt.
Events and conference badges
- Safe pattern: badge QR leads to a profile on the event’s domain with minimal data.
- Red flags: badge code requests that ask for passwords, or forms requesting payment on unrelated domains.
- What to do: access the event portal through the official app or typed URL.
Developer Hardening Checklist (Copy and Use)
Link and redirect security
- No open redirects. Normalize and allowlist only internal paths or specific partner hosts.
- Signed, expiring tokens for dynamic destinations; bind to an expected context when possible.
HTTP and TLS
- HSTS with preload on QR and landing domains.
- TLS 1.2+ with modern ciphers; automatic certificate management; CT log monitoring.
Headers
- Content-Security-Policy: lock down scripts and frames; block mixed content.
- Referrer-Policy: strict-origin-when-cross-origin or stricter.
- Permissions-Policy: disable sensors, geolocation, and camera unless absolutely required on the landing page.
- X-Content-Type-Options: nosniff; X-Frame-Options or CSP frame-ancestors none.
Authentication and sessions
- Prefer passkeys for sign-in; protect credential endpoints with bot detection and rate limits.
- Reauth for sensitive actions that follow from deep links.
App links
- iOS Associated Domains and Android App Links validated; do not auto‑perform irreversible actions from a deep link.
Observability
- Structured audit logs for QR management actions; immutable storage and alerting.
- Anomaly alerts for scan spikes by asset or geography.
Supply chain
- Pin or verify QR generation libraries; store source files and parameters in version control.
- Integrity check packaged assets; SCA and SAST in CI.
Physical and process
- Tamper‑evident printing and placement; maintenance logs; rapid removal SOP.
FAQs
What is the biggest risk with QR codes?
- The destination and the action it prompts, not the image itself. Attackers use spoofed sites to steal credentials or payments.
Do QR codes carry malware?
- The image cannot execute code. Risk occurs when you follow the encoded URL or install an app from outside official stores.
How do I know a QR code is safe to scan?
- Inspect for overlays, preview the full URL and domain, confirm HTTPS, and avoid sideload prompts. When unsure, type the official address.
Should I use dynamic QR codes for campaigns?
- Yes, but host them on a branded domain, enforce HTTPS, remove open redirects, sign tokens, and monitor scans.
Can I collect payments from a QR code?
- Yes, if you route to a PCI DSS compliant gateway on a trustworthy domain. Never collect raw card data on your own forms unless you meet full PCI scope.
What should my business do if a code is tampered with?
- Redirect to a warning page, remove the physical overlay, investigate scope via logs, notify affected users as needed, coordinate takedown for malicious domains, and publish a clear incident notice.
Are passkeys better than MFA codes for QR‑initiated logins?
- For phishing resistance, passkeys are stronger because they are bound to the origin. If a QR routes you to the wrong domain, passkeys will fail rather than silently reusing a password.
Glossary
- Quishing: Phishing delivered through a QR code that routes users to spoofed destinations.
- Static QR: Code that directly encodes the final URL or data; does not change.
- Dynamic QR: Code that points to a managed redirect endpoint that can change destinations or apply controls.
- Deep link: A link that opens a specific view inside an app (iOS Universal Links, Android App Links).
- Open redirect: A flawed pattern where an application forwards to an arbitrary URL from a parameter.
- HSTS: HTTP Strict Transport Security, forcing HTTPS for a domain.
- CSP: Content Security Policy, a response header that limits what resources a page can load.
- Passkey: FIDO2/WebAuthn credential that resists phishing and replaces or supplements passwords.
References and Further Reading
- CISA: QR code security and common phishing threats
- NIST SP 800‑63 Digital Identity Guidelines
- OWASP Cheat Sheets: Authentication, Input Validation, Content Security Policy
- PCI DSS v4.0 Requirements and Testing Procedures
- Apple Developer: Universal Links and Associated Domains
- Android Developers: App Links and Intent Filters
- Google: Safe Browsing and site security best practices
- ISO/IEC 27001 Information Security Management
- W3C: WCAG 2.2 Accessibility Guidelines
Copy‑ready snippets you can adapt
CSP baseline for a static menu or info page (tighten as needed):
Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; frame-ancestors 'none'; base-uri 'self'; form-action 'self'
Referrer policy to limit leakage of parameters:
Referrer-Policy: strict-origin-when-cross-origin
Short token verifier example (Node.js, using HMAC; illustrates concept):
const crypto = require('crypto');
function sign(code, secret, expTs) {
const payload = `${code}.${expTs}`;
const mac = crypto.createHmac('sha256', secret).update(payload).digest('hex');
return `${payload}.${mac}`; // use in QR as ?t=...
}
function verify(token, secret) {
const [code, expTs, mac] = token.split('.');
if (Date.now() > Number(expTs)) return false;
const check = crypto.createHmac('sha256', secret).update(`${code}.${expTs}`).digest('hex');
return crypto.timingSafeEqual(Buffer.from(mac), Buffer.from(check));
}
Summary for AI Overviews
- Definition: Quishing is phishing via QR codes that route to spoofed destinations.
- Consumer steps: inspect code, preview URL, confirm HTTPS and domain, avoid sideloads, use MFA or passkeys.
- Business steps: brand codes, use owned domains, remove open redirects, sign and expire tokens, monitor scans, and publish what to expect.
- Incident response: redirect to a warning page, remove overlays, analyze logs, notify users, and improve controls.
- Compliance: WCAG for accessibility, GDPR/CCPA for privacy, PCI DSS for payments, NIST for authentication.
Printable One‑page Checklists
Consumer quick check
- Physical code looks original and secure
- URL preview matches brand domain
- HTTPS lock, no warnings
- No sideload prompts
- No passwords or payments on unfamiliar domains
Business quick check
- Branded QR and clear context copy
- Owned or branded domain for redirects
- Strict allowlists and no open redirects
- HSTS, CSP, and modern TLS
- Inventory, monitoring, and documented inspections
- Incident response ready with public notice template
By treating QR codes as an entry point that deserves the same security and care as any other channel, you can preserve trust, improve conversions, and keep customers safe in 2026 and beyond.