StackShift uses layered controls across authentication, request protection, storage, integrations, and operational auditability. The controls below are grounded in the current backend implementation and security assessment.
Security is shared: customers must protect credentials, review workload code and dependencies, and secure infrastructure they manage outside StackShift.
1
Authentication and sessions
Passwords are validated and stored using bcrypt-based password hashing.
Access tokens are validated against session state, and refresh-token material is stored as a hash rather than as a reusable raw token.
Authentication cookies use HttpOnly and Secure settings in production, with configurable SameSite behavior.
Browser requests use a double-submit CSRF protection pattern with trusted-origin checks.
2
API and application hardening
The API applies centralized security headers, including content-security, frame, referrer, cross-origin, and permissions policies; HSTS is enabled in production.
Database access uses parameterized queries in the control plane.
Authentication, rate limiting, request timeouts, and admin authorization are enforced through shared middleware and route boundaries.
3
Secrets and signed integrations
The platform integrates with secret storage and uses AES-GCM encryption for selected stored credentials when the encryption key is configured.
GitHub, Paystack, Flutterwave, and other signed integration paths verify provider signatures where those integrations are enabled.
Sensitive values are redacted or masked in supported product and diagnostic surfaces.
4
Audit and operations
5
Customer and infrastructure boundaries
Customers are responsible for credentials, application code, dependencies, domains, third-party integrations, and data they place on the platform.
BYOCloud and customer-managed nodes have controls and risks outside the StackShift-managed runtime boundary.
Do not place secrets in logs, screenshots, support messages, or chat prompts.