Skip to main content

Security Practices

Bike4Mind follows industry-standard security best practices across its authentication, authorization, data validation, and deployment processes. Security is considered foundational in all stages of development and deployment.

Input Validation and Schema Enforcement​

All external inputs are validated using the Zod schema validation library. This ensures:

  • Strong typing and constraint enforcement at the API boundary
  • Early rejection of malformed or malicious inputs
  • Consistent validation rules shared across both client and server code

Schema definitions are colocated with each route or resource model, making validations transparent and easy to update.

Centralized Error Handling​

Error handling is unified through a shared asyncHandler utility and an Express-style error middleware. Benefits include:

  • Consistent API error responses (status code, message, metadata)
  • Clear error logging with trace context
  • Protection against accidental leakage of stack traces or internal details

Cross-Origin Resource Sharing (CORS)​

CORS policies are carefully controlled per environment:

  • Development environments allow localhost origins
  • Production environments explicitly whitelist known domains (e.g., app.bike4mind.com, staging.bike4mind.com)
  • Wildcard origins are never used in production

CORS rules are dynamically configured based on environment variables to support flexible deployments while maintaining safety.

Secrets and Configuration​

All sensitive values (e.g. database URIs, JWT secrets, third-party API keys) are managed via SST Secrets and environment variables. Key principles:

  • No secrets are committed to source control
  • Local development requires .env files that are not checked in
  • Deployment environments inject secrets at runtime through secure configuration layers

JWT Security​

  • JWTs are signed using a server-side secret and optionally rotated
  • Refresh tokens are used to extend sessions without weakening security
  • Tokens are validated for expiration, issuer, and audience before any permissions are granted
  • The platform supports short-lived access tokens to limit exposure in case of theft

Error and Edge Case Defense​

  • All unhandled promise rejections are surfaced and logged
  • API routes are guarded to prevent fall-through behavior
  • Routes reject requests from unauthenticated or unauthorized users by default
  • Sensitive error messages are never returned to clients; meaningful but non-revealing messages are provided instead

Platform Security Guidelines​

The following guidelines are followed across all development:

  • Never store sensitive user data (e.g. passwords, tokens) in the browser
  • Never rely on client-side enforcement for permissions
  • Always validate inputs on the server, even if validated on the client
  • Log security-relevant events (e.g. login failures, permission denials)
  • Design APIs assuming malicious intent from unauthenticated sources

Security Testing and Review​

New features and changes are reviewed with the following checklist:

  • Are all new inputs validated with Zod?
  • Are permission checks enforced using req.ability.can()?
  • Are routes protected via baseApi() middleware?
  • Are sensitive data and secrets excluded from responses and logs?
  • Are error messages sanitized and consistent?
  • Are logs and analytics capturing suspicious behavior where appropriate?

Security is not treated as a separate phase but is integrated into every code review, sprint, and deployment pipeline.