Security

This page describes the technical and organizational measures used to protect the Ride Labs platform. Last updated on November 12, 2025.

Authentication

All logins are handled through Google OAuth using a verified ID token on the server side. No passwords are stored or managed locally.

Sessions

Sessions are stored securely with signed session tokens and a server-side SQLite store that allows expiration and revocation.

Session cookies are marked HttpOnly, Secure, and SameSite=Lax.
Sessions can be revoked individually or globally via logout and logout_all actions.
Endpoints include me, auth/logout, auth/logout_all, gdpr/export, and gdpr/delete.

Security headers

The backend enforces a strict set of HTTP headers to reduce common attack vectors.

Strict-Transport-Security (HSTS) to force HTTPS.
X-Frame-Options to prevent clickjacking.
X-Content-Type-Options to block MIME sniffing.
Referrer-Policy to minimize data exposure in referrers.
Content-Security-Policy limiting allowed sources and form actions.

Attack surface and protection

We restrict origins, validate authentication flows, and apply basic rate limiting.

CORS is restricted to ridelabs.it and local development environments.
A nonce system helps validate login requests and prevent cross-site forgery.
Lightweight rate limiting prevents automated abuse of endpoints.

Infrastructure

The authentication backend runs on an Ubuntu environment hosted on AWS. The instance is isolated, monitored, and managed via systemd for continuous uptime.

Data minimization

Only essential authentication data is collected: Google UID, email, optional name, and timestamps. No analytics or marketing data are stored or processed.

Reporting and contact

If you discover a potential security issue, we encourage responsible disclosure and will respond promptly to any report.

See also our Privacy Policy for information on data handling.

Last updated: November 12, 2025.