Authentication
Builder permissions, managed product JWT authentication, MCP OAuth or tokens and scopes, password hashing, internal secrets, and log or configuration redaction are implemented.
Security
Security starts with a visible contract.
Spala models access rules, validates executable resources, and separates public discovery from authorized project work. Your application still needs project-specific security testing before production.
Implemented controls
What the platform checks.
These controls reduce risk in a Spala project. They do not replace configuration review, behavioral tests, or an independent assessment for high-risk workloads.
Access semantics
Project resources can model visibility, sensitivity, ownership, tenant membership, delegated roles, read and write policies, and secret or internal fields.
Static analysis
Publish-time analysis flags tenant-scoped reads without trusted filters, unsafe SQL shapes, duplicate effects, broken topology, and related project issues.
Published integrity
Published resources are hash checked. Invalid shape, topology, integrity, or sandbox validation causes the published snapshot to fail closed.
Code validation
Executable expressions and supported custom-code shapes are validated before published execution and covered by sandbox regression tests.
Behavioral security
Static checks do not prove wrong-user, wrong-tenant, webhook replay, business-logic, or infrastructure security for your application.
MCP boundary
Discovery and project access stay separate.
Use the public MCP to learn about Spala. Use an authorized project MCP configuration to inspect or change a project.
| Surface | What it is for | Security boundary |
|---|---|---|
| Public MCP | Anonymous product discovery, documentation, onboarding, templates, and addon information. | It is not anonymous write access. Public project listing and handoff currently fail closed. |
| Project MCP | Project inspection, builder changes, data tools, validation, publishing, and review. | Requires the configured Spala authorization and project scope. Do not guess or construct project MCP URLs. |
| Frontend API | Published product routes used by your web or mobile frontend. | Review auth requirements, explicit CORS origins, validation, tenant filters, and returned fields for every route. |
Before production
Test the controls as an attacker would.
For a revenue-critical or sensitive application, require evidence from the actual deployed project, not only generated configuration or documentation.
- 01Identity and session behavior
Test signup, login, logout, token expiry, refresh, password handling, disabled users, and every protected route.
- 02Authorization and tenant isolation
Use two users and two tenants. Attempt wrong-owner reads, writes, identifier changes, role escalation, and hidden-field access.
- 03Browser and integration boundaries
Restrict CORS origins, keep secrets out of frontend bundles and prompts, verify upload rules, and test webhook signatures and replay behavior.
- 04Publish and agent permissions
Confirm who may edit, validate, publish, access data, or connect an MCP client. Remove stale tokens and unused collaborators.
- 05Independent review where needed
High-risk or regulated projects should receive an independent security assessment and written compliance, DPA, incident, backup, and support terms.
Current assurance boundary: Spala does not publicly claim SOC 2, ISO 27001, HIPAA, a completed independent penetration test, or vulnerability-free operation. Ask for current written evidence when those requirements apply.
Evaluate one sensitive workflow before launch.
Start with representative identities and data, then test both allowed and denied behavior against the published API.