Subscription-based applications have become the norm, offering users flexible billing and access models. However, when handling subscriptions on the frontend, security must be a top priority. Misconfigurations can expose sensitive data, enable unauthorised actions, and even allow malicious actors to manipulate user subscriptions.
In this post, we’ll cover frontend safety recommendations for subscription management, API security, and best practices for integrating payment systems like Stripe and Salable without compromising user data.
Handling subscription scopes & API security
When working with Salable API scopes, a general rule applies:
💡 If a scope is not frontend-safe on any endpoint, then none of the endpoints using that scope are safe.
For example:
❌ licenses:get-all (Exposes vendor licenses, emails, and confidential pricing)
❌ subscriptions:get-all (Exposes purchaser emails)
✅ plans:get-all-currencies (Safe, does not reveal sensitive data)
Always assess API scopes before integrating them into your frontend. If unsure, restrict them to backend-only calls.
Why subscription management needs secure frontend practices
A user should be able to fully manage their subscription from the vendor’s app or via a secure external portal (e.g., Stripe, Salable).
They should be able to:
✅ View active subscriptions
✅ Check billing history & invoices
✅ Upgrade/downgrade plans
✅ Manage seats
✅ View usage records
✅ Cancel subscriptions
✅ Update payment methods
However, since most of these operations require authentication and sensitive data handling, direct frontend interactions must be limited to prevent unauthorised access or tampering.
Frontend do’s and don’ts: reading vs. writing subscription data
When building a frontend experience for subscriptions, developers need to distinguish between safe and unsafe API calls.
📌 Read operations (fetching data)
Not frontend safe 🚫
Some read operations expose personal or confidential data and should never be called directly from the frontend. For example:
❌ Invoices (contain email, address, and pricing details)
❌ Subscription data (exposes user emails and payment details)
Frontend safe ✅
Certain read operations can be done on the frontend as they don't contain sensitive information:
✔️ Subscription history
✔️ Subscription detail view
✔️ Coupons & promo codes
✍️ Write operations (updating data)
Not frontend safe 🚫
Never allow the frontend to perform write actions that affect user subscriptions directly. Doing so could expose API keys or allow attackers to manipulate subscription data. Unsafe actions include:
❌ Creating or updating licenses
❌ Changing subscriptions
❌ Updating usage records
❌ Cancelling/reactivating subscriptions
❌ Adding/removing seats
❌ Generating billing session links
Frontend safe ✅
Only a checkout link generation is safe to call from the frontend, as it simply allows users to subscribe via a secure external portal.
🔹 What about cancellation?
Instead of exposing cancellation actions in the frontend, consider directing users to email support or using a secure session-authenticated web component.
Securing API calls in the frontend
The danger of exposing API keys
Frontend-exposed API keys can be intercepted, leaked, or misused by attackers. A malicious user could:
- Read another user’s subscription details
- Modify their (or someone else’s) subscription
- Abuse promotional codes or licensing features
🔒 Solution:
✅ Use backend authorisation to verify users before executing any sensitive API calls
✅ Implement role-based access controls (RBAC)
✅ Avoid hardcoding API keys in frontend code
How to implement secure subscription management in your app
1️⃣ Web components with session authentication
A session-authenticated web component can allow users to manage their subscriptions securely. The backend validates the user and provides a token to the component, which then enables controlled actions like cancellation.
Example use case:
🔹 A cancellation button requiring backend authentication before allowing the action.
2️⃣ Secure pricing tables & free plan management
- "Free" plans without a payment integration require license creation, which must be authenticated via session tokens.
- Avoid exposing license creation endpoints directly in the frontend to prevent abuse.
3️⃣ Handling invoices securely
- Since invoices contain personal information, they should only be retrieved after authentication.
- Session authentication ensures only the authorised user can access their billing history.
4️⃣ Safe subscription checkout
Unlike other subscription modifications, checkout links are safe for frontend use.
- Users can create new subscriptions via secure hosted payment pages (e.g., Stripe, Salable).
- This approach eliminates the need for frontend-exposed API keys.
Final thoughts: prioritising frontend safety
Managing subscriptions in a web app requires a balance of usability and security. While giving users control over their subscriptions is crucial, handling it carelessly can expose sensitive data or allow unauthorised changes.
🔹 Key takeaways for developers:
✅ Only expose safe API calls from the frontend
✅ Use backend authentication for sensitive actions
✅ Implement session-authenticated web components for complex operations
✅ Follow regulatory best practices (DMA, GDPR, etc.)
✅ Never expose API keys in frontend code
By following these principles, developers can build secure, user-friendly subscription management systems that protect both the business and its users.
Got questions or need help implementing these best practices? Let us know here, or reach out to is in Discord!
Would you like any modifications or additional examples? Let us know! 😊
.png)
.png)
