Security model

All members must use multi-factor authentication (TOTP). Sign-up and sign-in include bot and fraud detection. The sign-in callback is checked against a state cookie.

Sessions use a random token in a __Host- cookie (HttpOnly, Secure, SameSite=Lax). We store only the token's SHA-256 hash. The identity provider's refresh token is stored encrypted. Sessions expire after 30 days, or after 7 days of inactivity.

Sessions check the member's role every 5 minutes. If the identity provider is unreachable, sessions keep working for 15 more minutes and then stop. Removing a member revokes their sessions. A role change applies from the member's next request.

Dashboard changes are accepted only from https://app.shiftlabs.org.

256 random bits. Each key has one workspace and one role, and expires after 1–365 days. We store its SHA-256 hash. The key is shown once. A key's role can't be higher than its creator's.

viewer < developer < admin, checked on every route. See what each role can do.

Each API query is scoped to the workspace of the credential used. The path and body can't change it. Requests for another workspace's trigger or run return 404.

Failed API authentication is rate limited per IP. After 10 failures in a minute, further attempts get 429.

Trigger ids are 128 random bits. Developers can rotate or revoke trigger URLs at any time. Viewers see them masked.

Each trigger can require a signature: shiftlabs (a secret we generate), stripe or github. Timestamped signatures must be within 5 minutes. Replayed deliveries are dropped.

Encrypted with AES-256-GCM and bound to their trigger. A generated secret is returned once. A secret you supply is not returned.

Per edge location: 100 requests per 10 seconds per trigger and 600 requests a minute per IP across the API and webhooks. At the edge, an IP sending more than 150 requests in 10 seconds to the webhook host is blocked.

A webhook body is capped at 256 KiB.

Failure alerts we post to your webhook are signed with your workspace's secret in the same Shiftlabs-Signature format. The secret is shown once and can be rotated. See how to verify one.

Each workspace's values are encrypted with its own data key (AES-256-GCM, bound to the workspace, the secret's name and its version). The data key is encrypted with a platform key.

Your code gets a stand-in instead of the value. The gateway replaces it with the value only for the secret's hosts (exact names, no wildcards or IP addresses, https only), and only if the stand-in was created in the same run. A request with a stand-in to any other host gets a 403. Text that only looks like a stand-in is not replaced.

A connection holds an auth template set by an admin. The workflow must declare the connection, and the host must exactly match one on its list. The gateway applies the template to each request to those hosts. The template overrides anything the code set. Redirects are not followed for requests that carry a secret.

If a response contains a secret, or a reversible encoding of it such as base64 or Basic auth, it is replaced with [redacted] before your code sees it. Readable secrets are scrubbed from logs.

reveal() returns only secrets marked readable. A secret marked hmac can only be used to sign, through sign(). Its value is not exposed to your code.

Each use or blocked use of a secret is recorded in the audit log, and so is each read of a run's payload or a workflow's deployed source, once per person per hour. Admins can read it at /v1/audit.

Every deploy is scanned. WebAssembly, crypto-mining code and raw sockets are blocked. You get a warning for hard-coded credentials and for URLs with IP addresses, unusual ports or shiftlabs.org hosts. Other patterns are flagged for review by our operators.

We check usage across workspaces every hour, including traffic concentrated on one host, failing or scanned targets, blocked requests and CPU use. New workspaces and workspaces whose current code is flagged have stricter thresholds. An operator reviews each flag.

When a workspace is suspended, its active runs are stopped, and webhooks, runs and API changes are rejected. You can still view and revoke triggers, API keys and members.

Send reports to abuse@shiftlabs.org with the X-Shiftlabs-Tenant value from the request. Only we can match that value to a workspace. Report a vulnerability in shiftlabs itself to security@shiftlabs.org, as described in Reporting a vulnerability.

The page, endpoint or feature affected, the steps to reproduce the problem, and what someone could do with it. Tell us which workspace you tested from. If you saw someone else's data, describe it; don't send it.

Test only in workspaces you own or have permission to test. To test isolation between workspaces, use two accounts of your own.

Don't access, change or delete data that isn't yours. If you reach some by accident, stop, don't keep a copy, and tell us.

No denial of service or load testing, no spam, and no social engineering or phishing of our staff or customers.

Give us reasonable time to fix the problem before you tell anyone else about it.

Research that follows these rules is authorized. We won't take legal action against you over it, and we won't treat it as a breach of the Terms of Service or the Acceptable Use Policy.

Problems in services other companies run, even ones shiftlabs uses: report those to their owners.

Runs execute in US regions only.

HTTPS only, TLS 1.2 or later, with HSTS. Plain HTTP requests get 403. The app, API and webhooks are each served only on their own hostname.

API responses are never cached and cannot be framed or content-sniffed.

Run telemetry uses separate write-only and read-only credentials.

This site loads no third-party scripts, fonts or trackers, and uses a strict Content Security Policy.