API security gaps in hospitality expose guest data and loyalty risk

At a glance

What this is: This is a Salt analysis of why hospitality APIs create concentrated exposure for guest data and loyalty assets when authentication, authorization and discovery do not keep pace with integration growth.

Why it matters: It matters because IAM, API security and data teams have to govern access paths that are both customer-facing and highly dynamic, where a single control gap can cascade into privacy, fraud and reputational loss.

By the numbers:

• Marriott’s 2018 breach affected nearly 500 million guests.

Context

Hospitality APIs sit between reservations, mobile check-in, loyalty systems and guest-facing applications, so they become a governance layer as much as a technical integration layer. When those APIs move personal data, payment details and reward balances, the real question is not whether they exist but whether access is continuously discovered, authenticated and authorised.

The security gap in this domain is often control drift rather than a single broken system. In fast-changing environments, hidden or neglected APIs can survive longer than the policies meant to protect them, which makes API security a practical IAM and data-governance problem, not just an application-layer issue.

Key questions

Q: What breaks when hospitality APIs are not fully inventoried?

A: Hidden or neglected APIs escape the same authentication, authorization and logging controls applied to known services. In hospitality, that means booking, loyalty and guest-profile data can remain reachable through forgotten paths even when the main application is well governed. The failure is operational blindness, because you cannot secure access you do not know exists.

Q: Why do weak API authorization checks create guest-data and loyalty risk?

A: A caller can be authenticated and still be over-authorised. If the API does not verify which record, balance or entitlement the caller is allowed to touch, attackers can enumerate guest data or drain loyalty value through legitimate-looking requests. The risk grows when business flows treat a valid token as proof of full trust.

Q: What are the signs that hospitality APIs are being abused at runtime?

A: Watch for high request volume against booking or loyalty endpoints, repeated object lookups, unusual redemption activity and access patterns that do not match normal guest journeys. These behaviours often indicate automation or business-logic abuse rather than conventional exploit traffic, which means perimeter tools alone will miss the threat.

Q: Who is accountable when API exposure affects guest data and loyalty systems?

A: Accountability sits across application owners, IAM teams, data owners and fraud teams, because the exposed asset is not just an API but the business process behind it. Organisations should define who owns discovery, who owns authorization policy, and who is authorised to halt suspicious guest-data or loyalty activity.

Technical breakdown

Why hospitality APIs expand the attack surface

Hospitality platforms rely on API-mediated transactions to connect booking engines, mobile apps, loyalty systems and customer service workflows. That architecture increases the number of reachable endpoints and the amount of sensitive data each endpoint can touch. The risk is not limited to public APIs; shadow, forgotten and partner-exposed APIs can carry the same data classes while remaining outside normal review cycles. In practice, exposure grows when inventory, authentication and access policy are not maintained as a single lifecycle.

Practical implication: Treat API inventory as a governance control, not a documentation task.

Authentication and authorization failures in API estates

APIs fail dangerously when they trust caller identity without strong authentication or when they authenticate a caller but do not constrain what that caller can access. In hospitality, that can mean a valid session or token is still able to enumerate reservations, loyalty balances or payment-related records outside its intended scope. The core issue is that business workflows often assume legitimacy once a client is known, while attackers abuse over-broad permissions and weak object-level checks to move laterally through data.

Practical implication: Map authentication and authorization checks to each sensitive API action, not just to login events.

Runtime abuse is the control gap WAFs miss

Conventional perimeter tools are poor at detecting business-logic abuse in APIs because the request often looks syntactically valid. Attackers can scrape loyalty points, enumerate guests or replay legitimate-looking calls at scale without tripping rules designed for known exploits. That makes runtime behaviour, anomaly detection and policy enforcement central to API defence. The governance problem is therefore not just whether the API exists, but whether abnormal use of legitimate API paths can be detected and constrained quickly enough to limit loss.

Practical implication: Add runtime abuse detection and response to API governance, especially where loyalty or payment data is exposed.

Threat narrative

Attacker objective: Steal guest data or monetise loyalty value by abusing legitimate API workflows at scale.

1. Entry occurs through an exposed hospitality API that is reachable from normal guest or partner workflows.
2. Credentialed or unauthenticated abuse then targets weak authentication or missing authorization checks to access records beyond the caller's intended scope.
3. The attacker can escalate by automating requests across bookings, loyalty accounts or other high-value objects, turning legitimate API functions into a data-exfiltration channel.
4. Impact includes guest-data theft, loyalty-point fraud and brand damage that is difficult to contain once the abused path is embedded in business operations.

Breaches seen in the wild

• T-Mobile API breach 2023: An attacker pulled data on 37 million T-Mobile accounts through one API, without authorisation, for six weeks before detection.
• McHire default password flaw 2025: A forgotten test admin account with the password 123456 and an API flaw exposed McDonald's McHire applicant records to researchers.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

API governance has become a hospitality trust control, not a narrow application-security task. Hotels now move customer identity, payment and loyalty value through APIs that change faster than many review processes can keep up. That creates a governance burden across discovery, access control and runtime monitoring, especially where customer journeys depend on external and mobile interfaces. Practitioners should treat API control coverage as part of the trust promise they make to guests.

Marriott is a cautionary signal about control drift, not just breach history. The article’s use of Marriott shows how repeated exposure concerns can persist when API estates are large, dynamic and only partially visible. The deeper lesson is that established brands are not immune to weak lifecycle governance around interfaces that carry highly valuable data. Practitioners should test whether their own API estate has the same drift between business speed and security oversight.

Hospitality loyalty programmes create a monetisable data layer that attackers will target. Rewards points are not just marketing assets; they are a conversion path from access to theft. When API calls can touch balances, profiles or entitlement fields without enough policy depth, fraud and identity abuse become operationally intertwined. The result is a security problem that spans IAM, fraud and customer trust, not a single control family.

Hidden APIs are the practical manifestation of the visibility gap this article exposes. If an organisation cannot account for all active interfaces, it cannot reliably govern authentication, authorization or exposure. This is the named concept the article points to: hidden API exposure, where unknown or neglected interfaces become the easiest route to sensitive guest data. Practitioners should make API inventory completeness a board-relevant risk signal.

From our research library:

• Secrets management is a top five cybersecurity priority for only 33% of organisations, behind cloud security (45%), API security (42%), and endpoint security (36%), according to the 2024 State of Secrets Management Survey.
• Read next: API Key Management Guide

What this signals

Hidden API exposure is the control gap hospitality teams should now treat as a governance metric, because unknown interfaces create unknown access paths. Once inventory drifts, authentication and authorization reviews become partial by definition, and the organisation is left relying on assumptions rather than control coverage.

Hospitality security teams should expect API risk to show up first in customer journeys, then in fraud and finally in brand trust. That sequence matters because loyalty abuse and guest-data exposure are operationally intertwined, so the response has to join IAM, application security and data governance rather than treating them as separate tickets.

For practitioners

• Build a complete API inventory Catalogue public, partner and internal hospitality APIs, then tie each endpoint to an owner, data class and review cycle so hidden or neglected interfaces do not sit outside governance.
• Enforce object-level authorization checks Verify that every reservation, loyalty and guest-profile API call is constrained by caller context, not just by session validity, so valid tokens cannot reach unrelated records.
• Review API access to loyalty data Separate reward balances, redemption actions and profile updates into distinct policy paths so fraud teams and IAM teams can limit monetisable abuse.
• Instrument runtime abuse detection Monitor for high-frequency enumeration, unusual replay patterns and business-logic abuse across guest-facing APIs, then trigger containment when behaviour diverges from normal booking flows.

Key takeaways

• Hospitality API estates create a broad and fast-moving exposure surface for guest data, payment information and loyalty assets.
• The largest control gap is not simply whether APIs exist, but whether the organisation can continuously govern discovery, authorization and runtime behaviour.
• Teams that cannot map and enforce access at the API level leave themselves open to data theft, loyalty fraud and trust damage.

Key terms

• API Inventory: An API inventory is the authoritative record of what interfaces exist, who owns them, what data they touch, and how they are authenticated. For identity governance, it is the baseline control that makes review, monitoring, offboarding, and risk prioritisation possible across distributed services.
• Broken authorisation: A failure in which an API allows a caller to access data or functions outside its permitted scope. The problem can appear as object-level or function-level abuse, and it often survives if teams only test happy-path behaviour.
• Business Logic Abuse: Business logic abuse occurs when an attacker uses a valid API in a way the application designer did not intend, such as exceeding limits, chaining actions, or misusing workflow assumptions. The API is functioning technically, but governance and policy are failing at the intent layer.
• Hidden API: A hidden API is an application interface that exists in a system but is not intended for public or routine use. It may support internal functions, undocumented integrations, or legacy behavior. In security analysis, hidden APIs matter because they can expand attack surface, bypass governance, and create unmanaged access paths.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is suitable for practitioners building stronger access governance across human, machine and delegated identity paths.