Building a great SaaS product isn’t just about features and design—it’s about earning and keeping your users’ trust. A secure application is the foundation of that trust. While Saasio provides a secure infrastructure and powerful tools out of the box, the security of your final application also depends on the choices you make as a builder. This guide outlines the key principles and best practices you should follow.
The Shared Responsibility Model
Think of security as a partnership.- Saasio’s Responsibility (The Secure Foundation): We provide a secure, robust infrastructure. We handle things like server security, database protection, encrypting your secrets, and providing secure, pre-built actions.
- Your Responsibility (The Secure Blueprint): You are responsible for using Saasio’s tools correctly to build secure application logic. This includes protecting your pages, validating data, and managing user permissions.
What Saasio Secures for You Automatically
You get a huge head start on security just by building on Saasio. Here are some of the things we handle for you:Secure Backend
All your sensitive logic, like database queries and API calls, runs on the
Saasio backend, never in the user’s browser where it could be exposed.
Encrypted Secrets
Any value you save as an Environment Variable is encrypted at rest and
can never be viewed again in the editor, ensuring your API keys and tokens
are safe.
Secure Authentication
Our built-in Account Actions (Login, Sign-up, Logout) use
industry-standard security practices to manage user sessions and protect
passwords.
Webhook Verification
Actions like “Get Stripe event” automatically handle complex security
checks (like signature verification) to ensure that incoming webhooks are
legitimate and not malicious.
Your Checklist: 6 Best Practices for Secure Building
As a builder, your primary job is to ensure your application’s logic is secure. Here are the most important practices to follow.1. Never, Ever Expose Secrets on the Frontend
1. Never, Ever Expose Secrets on the Frontend
This is the most important rule of web security. Any logic that runs on the Client (in the user’s browser) can be viewed. Therefore, you must never place secret API keys or tokens in a frontend workflow.
- Do This (Secure): Store your key in an Environment Variable and use it in a Server-side Function or API Route.
- Never Do This (Insecure): Paste a secret key directly into a “Make an API call” action that is part of a frontend workflow.
2. Protect Your Pages and Data
2. Protect Your Pages and Data
Not all users should see all pages. Always add a security checkpoint to pages that contain sensitive information.
- Best Practice: On any protected page (like a dashboard), use the “On Page Load” workflow to check if the
Current User's statusisunauthenticatedand redirect them to the login page. (See the Authentication Tutorial).
3. Implement Role-Based Access Control (RBAC)
3. Implement Role-Based Access Control (RBAC)
Just because a user is logged in doesn’t mean they should be able to do everything. Use roles to control access to features.
- Best Practice: Add a
rolefield to yourUserstable (e.g., “user” vs. “admin”). Before running a sensitive action (like deleting a user), use a Conditioner to check if theCurrent User's roleis equal toadmin.
4. Use Server-Side Logic for Sensitive Actions
4. Use Server-Side Logic for Sensitive Actions
Any action that modifies important data, grants permissions, or processes payments must be executed on the server.
- Best Practice: Instead of putting complex logic in a button’s “On Click” workflow, create a Server-side Function for the task (e.g.,
ProcessPayment). The button’s only job is to trigger that secure function. This prevents users from manipulating the logic from their browser.
5. Validate All Data on the Server
5. Validate All Data on the Server
Frontend validation (using a Zod Schema on a Form) is great for user experience, but it can be bypassed. True security comes from server-side validation.
- Best Practice: In any API Route or Server Function that receives data, your first step should be to use the “Validate Data” action to check the incoming data against a Zod Schema before you save it to the database.
6. Conditionally Render Sensitive UI Elements
6. Conditionally Render Sensitive UI Elements
Don’t show buttons or links for actions a user isn’t allowed to perform.
- Best Practice: Use a Condition on your UI elements to control their visibility. For example, an “Admin Panel” button should have a condition to hide it (
display: none) if theCurrent User's roleis notadmin.