Posting Your Boarding Pass Can Cost You the Account: What We Measured About QR Redaction
What a single ticket stub gives away
Start with a documented case, not a hypothetical.
Security journalist Brian Krebs wrote this up in 2015. A reader named Cory saw a friend post a boarding pass photo on Facebook, screenshotted it, enlarged the barcode, and ran it through a free online barcode decoder. Seconds later he held the friend's frequent flyer account details.
What followed is the part worth sitting with. Cory could view every future flight on that account, change seats for ticketed passengers, and cancel any upcoming flight. The exposed data was also enough to clear the early stages of the airline's "forgot PIN" reset flow.
The friend had simply posted a happy travel photo.
Most people miss one thing here: barcodes and QR codes are not decoration — they are machine-readable data containers. You see black and white squares; a scanner sees a booking reference, a name, a flight, a date, a seat. That gap is the whole risk.
Partial redaction does not work, and I tested how badly
This is the section I most wanted to write, because the wrong redaction method is more dangerous than none — you believe you are safe and post it anyway.
QR codes are designed with substantial error correction. The specification lets a scanner reconstruct the full payload even when a meaningful fraction of the symbol is damaged, dirty, or obscured. In the physical world that is genuinely useful — creased tickets and smudged prints still scan. Applied to "I'll just cover half of it," it becomes a vulnerability.
So I ran the test.
How much area do you actually have to cover?
The method is reproducible if you want to check it. I generated a mock voucher QR code with Python's qrcode library — the payload is a redemption URL carrying a booking reference and a validation code — at error-correction levels M (15%), Q (25%), and H (30%). Each was subjected to four redaction methods across seven area ratios, then decoded with OpenCV's QRCodeDetector. Only a full recovery of the original URL counted as "still readable."
The results were worse than I expected.
| Redaction method | Fails at (M, 15%) | Fails at (Q, 25%) | Fails at (H, 30%) |
|---|---|---|---|
| Solid block, centered | 15% of area | 20% of area | 25% of area |
| Solid block, bottom-right corner | 20% of area | 25% of area | 25% of area |
| Horizontal bar across | 10% of area | 20% of area | 20% of area |
| Pixelation, centered | 15% of area | 20% of area | 25% of area |
Read it as: that percentage is where decoding starts to fail. Anything below it still scans.
Three findings worth keeping.
First, a high-EC ticket still decodes with a fifth of its area covered. At level H with 20% obscured, centered blocks, corner blocks, and pixelation all recovered the payload. That reasonably-large rectangle you drew over the code blocked nothing.
Second, pixelation performed identically to a solid block — the same failure thresholds at all three levels. This kills the intuition that blurring is at least better than nothing. It is not safer; it only looks like you did something.
Third, the horizontal bar was the most effective of the four. At level M a bar covering 10% of the height already broke it. A bar spans the full symbol width, so the damage lands across multiple codeword blocks, while a compact square happens to sit exactly where error correction is strongest.
Frankly, that third result contradicts the conclusion I set out to write. Security advisories warning that "drawing lines through a ticket does not void it" are correct — they are talking about the credential remaining valid and readable. But if the question is which crossing-out style best defeats a scanner, this data says bars beat blocks. You only learn that by measuring.
Where you cover matters more than how much
The most useful result came last.
The three large squares in a QR code's corners are finder patterns — scanners use them to establish orientation and boundaries. I covered the top-left one, and all three error-correction levels failed to decode — while that patch occupies only 2.0% to 3.6% of the total image area.
Put differently: covering 2% of the right place beats covering 20% of the wrong place.
Note the boundaries of this test. I used OpenCV's decoder, a single payload, and a single QR version. Commercial scanners and phone cameras implement recovery differently and may be more capable. Treat these thresholds as a floor, not a guarantee — a real attacker's decoder is likely more forgiving than my test environment.
Practically, the standard is one line: cover the entire code with an opaque block, past its edges. Not a corner, not a few lines, not pixelation. If your tooling will not allow that, at minimum ensure one of the three finder corners is completely covered.
Cover it properly or you have not covered it.
Three layers of exposure in travel screenshots
Travel screenshots split into three layers with genuinely different risk profiles and different fixes.
| Layer | Typical source | What leaks | Worst case |
|---|---|---|---|
| Scannable credential | Klook / GetYourGuide vouchers, event tickets, boarding passes | The credential itself, PNR, loyalty account leads | Ticket redeemed by someone else, account takeover |
| Textual identifiers | Booking.com / Agoda confirmations, reference numbers, room numbers | Name, stay dates, property address | Impersonation calls to the property, social engineering |
| Embedded image data | Photographing a screen instead of screenshotting | EXIF GPS, capture time, device | Your location or home address inferred |
Layer one is the urgent one. The value of an e-voucher is the code itself; once someone scans it first, you discover the problem at the gate. There are documented cases of criminals lifting posted event tickets, altering them, and defrauding would-be buyers — the poster is not the only victim.
Layer two looks harmless and is social engineering fuel. Name plus stay dates plus property is enough to call the front desk posing as you, or to call you posing as the property to "re-confirm your card." This spikes during peak travel season.
Layer three gets overlooked most. Phone screenshots normally carry no GPS, but photographing a screen with a second device stamps that image with where you were standing. More common than you would think when sharing a laptop display.
What to do when companions genuinely need the details
This is the real constraint — trip logistics require sharing. Meeting times, ticket contents, the hotel address.
In priority order:
Use the platform's native sharing first. Klook, GetYourGuide, Booking.com and most others support sharing or transferring a booking to a travel companion. Through official channels the credential's validity stays under platform control and no screenshot enters circulation.
Second choice: send text, not an image. "Sept 26, 9am, main gate, I have the tickets" carries everything needed at zero risk.
Third choice: share an image with access control. For genuinely visual content — a complex itinerary table, a map — use something with access control rather than a public post.
With lpic.cc you can set a view password at upload, so the short link resists forwarding. Passwords are stored bcrypt-hashed rather than compared in plaintext. For "only these five people" itinerary screenshots, that is meaningfully more controlled than dropping it in a group chat to circulate freely.
State the limits up front: images cap at 8MB, files are retained 30 days after the last view, and uploads are automatically optimized so originals are not preserved. Also — a password stops people who should not see it, but not an authorized viewer screenshotting and forwarding. Every sharing mechanism shares that ceiling. Do not treat it as absolute.
The last line of defense stays the same: genuinely sensitive credentials should never become image files in the first place.
FAQ
Q1: I posted a boarding pass a while ago. Does deleting it help now?
Deleting limits further exposure but does not prove nobody captured it. Two things matter more: change that airline account's password and security-question answers immediately, and check upcoming reservations for unauthorized changes. In the Krebs case, changing seats and cancelling flights were the first things available to the attacker.
Q2: Someone scanned my Klook voucher. Can I still get in?
Depends on the ticket type. Single-redemption vouchers show as already used at the gate. Contact platform support immediately, though outcomes are not guaranteed and peak-season response is slow. Prevention beats remediation here by a wide margin.
Q3: Is pixelating the QR code enough?
No, and I measured it. Across all three error-correction levels, pixelation and solid blocks had identical failure thresholds — a high-EC ticket needed 25% of its area covered before it stopped scanning. Use an opaque solid block over the whole code region, or better, block it physically before taking the picture.
Q4: My confirmation only shows a reference number and a name. Still risky?
Yes. Name plus reference is enough to query booking status on some platforms, and adding stay dates completes a social engineering kit. The recurring pattern in real cases is that attackers never need your password — only enough fragments to convince a support agent.
Q5: What about the travel photos themselves?
Different risk. Photo exposure is mainly EXIF GPS. Most social platforms strip EXIF on upload, but cloud drives and "send as original file" paths usually preserve it intact. Our field-by-field EXIF retention test across 8 image hosts covers how different services handle it.