At 3:14 AM on a Tuesday, a script running from a rotating residential proxy pool made its 41,000th request to a rewards platform's redemption endpoint.
It wasn't exploiting a CVE. It wasn't bypassing a WAF. It was doing exactly what the API was designed to do redeem points for gift vouchers except it was doing it on behalf of 3,200 user accounts whose session tokens had been harvested from a credential-stuffing run three weeks earlier.
By the time the security team noticed, points worth ₹2.8 crore had been converted into Amazon vouchers and resold on Telegram channels at 60% of face value.
The post-mortem said what every loyalty post-mortem says:
"We are treating this as an account security incident and have reset affected users' passwords."
Translation: we still don't know how to talk about this.
That inability to talk about it clearly, structurally, with the right vocabulary is the problem this series exists to solve.
The Industry That Forgot to Grow Up
Loyalty and rewards is valued in the hundreds of billions of dollars globally. In India alone, loyalty programs process more points annually than the total transaction volume of several listed fintech companies. Every major bank runs one. Every major airline runs one. Every major retailer runs one. Most of them outsource the platform to a handful of shared vendors which means a single technical failure at a single vendor can cascade across the country's banking sector.
And almost none of these platforms are secured as if points were money.
Here is the founding lie of most loyalty platforms:
"Points are a marketing construct. They're not real money."
This sentence or some version of it has been spoken in so many product meetings that it has become operational truth. Points are booked as a marketing expense. They are built by growth teams. They are secured, if at all, by whoever had spare capacity.
But ask a different set of questions:
- Can you redeem points for flights, hotel nights, or electronics?
- Can you redeem them for gift cards indistinguishable from cash?
- Can you transfer them to another user?
- Is there a secondary market where they trade for real currency?
If the answer to most of these is yes and for every major loyalty platform, it is then points are not a marketing construct. They are a bearer financial instrument with no regulator, and the platform issuing them is a fintech company in marketing-department clothing.
The security implications of that reframe are the entire reason this series exists.
Why Attackers Love Loyalty Platforms
If you are a bug bounty hunter or an offensive security researcher, here is the pitch:
Loyalty platforms are where fintech security was in 2012.
High-value. High-volume. High-complexity. Almost universally under-secured relative to the financial impact of compromise. Outside PCI scope. Outside most regulatory frameworks. Outside the attention of most internal security programs. And transacting real value every second of every day.
A short, incomplete catalogue of what actually gets found on loyalty platforms:
1. Redemption race conditions Two concurrent requests redeem the same 5,000 points for two different ₹500 vouchers. If the balance check and the deduction aren't atomic or if voucher issuance runs in a separate service from wallet debit the attacker walks away with ₹1,000 of value for ₹500 of points. Scale that across 10,000 accounts. This is the loyalty platform's version of race-the-withdrawal, and it is still one of the highest-impact findings in this target class.
2. IDOR on wallets, transactions, and redemptions GET /api/v2/users/10045782/wallet → increment the ID → read another user's balance, transaction history, linked cards, redemption trail. In poorly-scoped platforms, issue redemptions on their behalf. Loyalty APIs are notorious for this because they were often built as "internal" services before being exposed to a mobile app, and the authorization model never caught up.
3. Earn manipulation Replay the "transaction completed" webhook that credits points. Tamper with the amount field in a client-side earn event. Trigger referral credits with self-generated referrals. Exploit tier-based earn multipliers by briefly spoofing tier status. These bugs don't look like vulnerabilities in any classical sense — they look like misunderstood trust boundaries between the earn pipeline and its upstream sources.
4. Business logic in redemption rules Find the rule engine. Find the edge case no one tested. Redeem ₹1 of points for ₹10 of value because rounding favors the attacker. Redeem a voucher whose expiry check happens client-side. Stack promotions that were never meant to stack. Business logic is where the most creative and most profitable loyalty attacks live.
5. Token and session flaws in financial context JWE tokens exposed in GET parameters (and therefore in referer headers, access logs, and analytics pipelines). Session cookies without SameSite. Long-lived refresh tokens that outlast forced password resets. All of these are bad anywhere. They are worse when the token authorizes the movement of real financial value without a second factor.
6. Partner integration leaks Bank ↔ airline ↔ loyalty vendor ↔ gift card provider. Each handoff is an API, an auth model, and a data contract. Any one weak link compromises the chain. Shared vendor risk is massively underappreciated here a single SaaS loyalty provider serving five major banks is a single point of failure for five major banks, and the threat model rarely reflects that.
7. Unauthenticated exposure of internal surface An unauthenticated manage_orders page with internal field names exposed in the DOM. A public developer portal hosting production API schemas and auth flows. CORS set to `*` on an endpoint returning redemption history. These findings don't require exploitation skill they require looking. And on loyalty platforms, the returns on simply looking are disproportionately high.
Every pattern above has been observed on production loyalty platforms within the last three years. None of them require nation-state tooling. All of them cause direct, quantifiable financial loss.
Why Existing Frameworks Don't Help
You are a security engineer trying to formally assess the posture of a loyalty platform. You open the toolbox.
PCI-DSS Most loyalty platforms don't directly touch cardholder data. Largely out of scope and the controls that do apply don't cover redemption, earn, or wallet logic at all.
OWASP Top 10. Catches some of the technical findings above. Is effectively silent on business logic, earn manipulation, referral fraud, and redemption edge cases which together make up the majority of real impact.
OWASP ASVS. Strong on web application fundamentals. Domain-agnostic by design. Won't tell you whether your rule engine is safe.
Microsoft SDL / NIST SSDF. Lifecycle frameworks, not threat models. They tell you when to assess. They don't tell you what to assess in a loyalty context.
ISO 27001. Excellent for information security management. Silent on whether your points engine is exploitable.
The gap is not that these frameworks are bad. They are load-bearing, and you should still use them. The gap is that no framework exists for the loyalty-specific attack surface, and that absence has different consequences for different readers of this series:
a. If you are a security engineer, you can follow every framework correctly and still ship a platform exploitable in week one. b. If you are a bug bounty hunter or pentester, you have no canonical checklist for this target class. You improvise scope every engagement and rediscover the same bug patterns by accident. c. If you are in GRC, you cannot produce a defensible risk narrative for a loyalty platform. No quantification model. No benchmark. No repeatable audit trail. d. If you are a product or engineering leader, you have no shared vocabulary with your security team for what a "secure loyalty platform" even means.
LARS is the attempt to close all four gaps with a single framework.
What LARS Is
LARS : Loyalty Application Risk Scoring is a domain-specific risk scoring model for loyalty and rewards platforms.
It sits on top of existing frameworks, not beside them. Threat modeling still applies. STRIDE still applies. Your SDL still applies. LARS is what you plug into the "what's specific to loyalty?" gap those frameworks leave open.
LARS scores a platform across five dimensions:
1. Redemption Risk: Can value leave the platform in ways it shouldn't? 2. Identity Risk: What is the blast radius when an account is compromised? 3. Integration Risk: How exposed is the platform through its partners and vendors? 4. Data Risk: What is accessible, to whom, under what conditions? 5. Business Logic Risk: Do the rules of the platform contain exploitable design flaws?
Each dimension scores on a structured 0–20 scale. The aggregate is a LARS rating out of 100 lower is better, and anything above 60 represents material residual risk worth escalating to leadership.
The dimensions, the scoring methodology, and the full scorecard are what the rest of this series builds out.
Who This Series Is For
Security engineers Use LARS as a threat modeling lens, a design review checklist, and a pre-launch readiness gate. Each dimension maps directly to SDL phases: requirements, design, implementation, verification, and release. By the end of this series, you will have a repeatable way to bring a loyalty platform from "we've tested it" to "we have a score."
Bug bounty hunters and penetration testers Use LARS as a methodology. Each dimension corresponds to a cluster of attack classes with specific technical patterns some of which were sketched above, all of which will be developed in depth in Article 2. For black-box engagements against loyalty targets, LARS is the closest thing you'll find to a domain-specific testing checklist, with the side benefit of giving your reports a scoring framework your clients can actually operationalize.
GRC professionals Use LARS as a quantification and reporting framework. The scorecard produces a defensible, repeatable risk metric. Track LARS score across quarters. Present LARS results to the board. Use LARS to benchmark third-party loyalty vendors during procurement due diligence. When a regulator or auditor asks "how do you assess loyalty risk?", you now have an answer more specific than "we follow industry best practices."
Product and engineering leaders Use LARS as a shared vocabulary between security and product. Instead of "we need better security" (vague) or "we have 14 open findings" (noisy), the conversation becomes: "our Business Logic Risk is scoring 17/20 here's the three-sprint plan to bring it under 10."
This series is written so that a first-year AppSec engineer, a GRC analyst two years out of law school, a senior pentester, and a VP of Engineering can all read the same article and take away something useful for their role. The technical depth builds gradually. You do not need to know what a race condition is to understand Article 1. You will by Article 3.
The Uncomfortable Truth
Most loyalty platforms have never been assessed against a loyalty-specific threat model. Not because the teams are incompetent. Because the model didn't exist.
We built our loyalty platforms on the assumption that points aren't money. We built our security programs on the assumption that loyalty platforms aren't fintech. We built our compliance frameworks on the assumption that if something isn't regulated, it doesn't need to be measured.
Attackers never accepted any of these assumptions.
They have been quietly, profitably, and at scale extracting value from loyalty platforms for a decade. The platforms don't always know. The users often don't know. The regulators mostly don't care yet.
LARS is a bet that this changes. That the industry reclassifies loyalty as financial infrastructure. That security teams measure loyalty risk with the same rigor as payment risk. That bug bounty programs scope loyalty targets honestly and pay accordingly. That GRC teams get a real framework to use.
This series is that framework.
What's Coming Next As Part Of My Real Experience
Article 2 The Five Dimensions. A deep technical dive into each LARS dimension: what it measures, what attack classes it captures, what signals to look for when scoring it. This is the article bug bounty hunters and pentesters will bookmark.
Article 3 Scoring in Practice. Walking a realistic loyalty platform through LARS end-to-end. What a 22/100 looks like. What an 81/100 looks like. What to do with the number once you have it.
Article 4 LARS in the SDL.
Where LARS plugs into requirements, design review, code review, pentest scoping, and release gating. For the security engineer who has to make this operational on Monday morning.
Article 5 The LARS Scorecard. The framework as a one-page, downloadable artifact. For teams that want to self-assess and track posture over time.