Hacking the largest airline and hotel rewards platform (2023)

Incident response and vulnerability disclosure

• Many commenters are impressed that points.com repeatedly:
  • Acknowledged reports within an hour.
  • Took affected sites offline quickly.
  • Deployed fixes rapidly.
• This is contrasted with common experiences where security reports sit in generic inboxes for hours or days.
• Some speculate they use security.txt plus a managed disclosure program, possibly with 24/7 operations-style monitoring and escalation.
• Others note a disconnect: incident response is very strong while some underlying bugs are extremely basic.

---

Bug bounty culture and incentives

• Several comments criticize parts of the web bug bounty community as ego-driven and impatient toward companies.
• Desired changes:
  • More and better-paid bounties.
  • Less public shaming and more professionalism.
• There is concern that “move fast and fix” expectations could be abused as a social-engineering vector (e.g., fake reports that pressure rushed, unsafe changes).
• Example cited of a very high bounty for an error involving an accidentally pasted cookie, raising questions about what counts as “skill.”

---

Basic security failures (e.g., SECRET_KEY="secret")

• Commenters are shocked that a global admin site used “secret” as the Flask session key, enabling cookie re-signing with superadmin rights.
• Explanations offered:
  • Example code copied with a placeholder key.
  • A ticket to replace it with vault-managed material is never completed.
• Debate on session design:
  • Some argue cookies should only store an opaque ID, with all auth data server-side.
  • Others defend Flask’s signed-cookie model but stress the need for strong, protected keys.
• Framework comparisons:
  • Django is praised for generating random secret keys and using DB-backed sessions by default.

---

Development practices vs. security practices

• Discussion on how “donkey” development practices can coexist with sharp security teams.
• Some argue organizations should move strong security talent into build teams to prevent vulnerabilities earlier.
• Others note many security specialists don’t want to be developers, so simple reshuffling isn’t realistic.
• Several mention common patterns:
  • Weak or default secrets in dev that leak into prod.
  • “Temporary” shortcuts and tech debt turning into long-lived attack surface.

---

Airline, GDS, and rewards ecosystem insecurity

• Commenters generalize from the article to the broader travel industry:
  • Rewards portals often feel like low-quality reskins with poor security.
  • Many airline systems rely on easily guessed or exposed identifiers (PNR + surname) to access and sometimes modify bookings.
  • Boarding pass barcodes can leak these identifiers; posting them online can enable itinerary tampering or denial-of-service (cancellations).
• Trade-offs highlighted:
  • Stronger auth and MFA would increase complexity for many interconnected parties (airlines, GDSs, OTAs, hotels, agencies).
  • Some defend the current model as a pragmatic balance between usability, interoperability, and risk.
• Others describe deeper, legacy issues:
  • Arcane and brittle GDS backends.
  • Misconfigured or exposed endpoints that can be abused for fare manipulation, refunds, or “fuel dumping”-style exploits.
  • Tech debt is high; fixes are expensive, and abuse is traceable enough that systems often remain unfixed.

---

Whether to take sites offline for vulnerabilities

• One camp: with significant financial exposure, once a critical flaw is proven, keeping the system online is unacceptable, possibly illegal or insurance-violating.
• Another camp: the “optimal amount of fraud is non-zero”; if exploitation isn’t widespread and uptime is highly valuable, some organizations might rationally keep running temporarily.
• Counterargument: knowingly running with a “broken lock” on other people’s assets is ethically and legally different from tolerating minor shoplifting.

---

Rewards programs and economics

• Some users say rewards portals are inherently second-class systems because they cost money rather than directly generating revenue.
• Others counter with experiences of extremely profitable but technically crude revenue-generating systems.
• A security researcher notes airline bounties paid in miles can be tax-inefficient:
  • Points are treated as taxable gifts, generating tax bills that can exceed the value of flights compared to just paying cash.

---

Meta observations

• Commenters see these vulnerabilities as:
  • Evidence that well-known, decades-old issues (directory traversal, weak secrets, authz mistakes) remain common.
  • A natural result of early-stage shortcuts that survive growth until an external researcher exposes them.