Security at Swastik Codes

An API client handles tokens, keys and production URLs, so we treat security as part of the product. This page describes our safeguards and how to report a vulnerability.

Your data: short answers

Where are my collections, environments and responses stored? In a cloud workspace they are stored in our access-controlled database so they sync between your devices and teammates. In a local workspace (Scratch Pad, or any workspace marked "On this device") they stay in your browser or the desktop app and never reach our servers. Current values of variables and vault secrets always stay on your device.

Do requests and responses pass through your servers? In the web app, yes: browsers cannot call most APIs directly, so our server sends the request and returns the response, in memory. The desktop app and the swc CLI send requests straight from your computer. History is saved only while Save responses is on, keeps the newest 500 entries per person and workspace, and workspace admins can set how long it is kept.

Is my data used to train AI models? No. Swastik Codes has no AI features that send your collections, requests or responses to an AI provider, and we do not use them to train models.

Can I turn cloud sync off? Yes. Work in a local workspace or in the desktop app and nothing is synced. You can export everything (collections, environments, the whole workspace) at any time in standard formats.

How are tokens and keys protected? Passwords are Argon2 hashes; refresh tokens and API keys are stored only as SHA-256 hashes, access tokens expire after 15 minutes, and API keys need a verified email and can be revoked at any time. An API key acts as your account, so create one per machine or pipeline and revoke it when it is no longer needed.

Can teams restrict access? Each workspace has admin, editor and viewer roles that every API route checks, and workspace admins see an audit log of who saved, deleted, shared, published or restored what.

What about retention, backups and recovery? Deleted items stay in the trash for 30 days and collections keep their version history. Workspace admins set how long history, monitor runs and the audit log (365 days by default) are kept. We back up the database before every release.

How is Swastik Codes tested for security? Every release runs our automated test suite, including the tests for sign-in, sessions, two-factor codes, workspace permissions and the network safeguards below. After each release, our own security checks (swc security) run against swastik.codes: transport and security headers, CORS, cookie flags, version banners, error details, sensitive fields and endpoints that answer without credentials. A medium or high finding fails the release check.

Do you hold security certifications? Not yet: Swastik Codes does not hold compliance certifications such as SOC 2 or ISO 27001. We will list any here once they are actually obtained, rather than claim them in advance.

How we protect your account

Passwords are stored only as salted Argon2 hashes. Passwords must be at least 8 characters long.
Sessions use short-lived access tokens (15 minutes by default) and refresh tokens that rotate on every use. If a refresh token is ever reused, the whole session family is revoked. Refresh tokens and API keys are stored only as SHA-256 hashes.
Sign-in protection. Repeated failed sign-ins lock the account temporarily, and sign-up, sign-in and password reset are rate limited per IP address.
Session control. Under Account settings you can see each signed-in device with its browser and IP address, sign out one device or all others, and revoke API keys. Changing or resetting your password signs out every other session.
Email verification and one-hour password reset links.
Two-factor sign-in. Turn on a second step with any authenticator app (Google Authenticator, Microsoft Authenticator, 1Password, Authy) under Account settings → Security. Every sign-in, with a password or with GitHub, then needs a 6-digit code; each code works once, five wrong tries end the attempt, and ten single-use recovery codes cover a lost phone. The secret is stored encrypted.
Sign in with GitHub. GitHub's client secret stays on our server. Every sign-in uses a single-use code that expires in minutes and must finish in the browser that started it, so nobody can sign you into their account or theirs into yours. The desktop app uses your system browser with PKCE and never sees a GitHub token. An account is matched to GitHub only through an email address GitHub has verified; if someone had registered that address without verifying it, their password, sessions and API keys are removed when the real owner signs in.
Connected GitHub repositories. Repository access is a separate consent from signing in. The token is encrypted on our server and never reaches the browser or the desktop app; connecting must finish in the browser that started it. Webhook deliveries are verified with a per-repository HMAC-SHA256 secret, code is read in a temporary folder with size limits and deleted after each scan, and nothing in it is run. A sync only uses the GitHub access of someone who can still edit the workspace, and pointing a sync at another branch or folder switches it to your own access. Disconnecting revokes the token at GitHub.
Delete your account at any time under Account settings → Security. Your personal workspace and everything in it go with it.

How we protect your workspaces

Roles. Every workspace has admin, editor and viewer roles, and every API route checks them. People who are not members get a "not found" response, so they cannot even confirm that something exists.
Secrets stay local by default. Current values of variables are kept on your device and stripped before anything is stored on our servers; only initial values sync.
Secret guard, on by default. When you save a request that holds a token, API key or password typed in as plain text, the app warns you and offers to move it into a variable or the vault. Exports show how many secrets a file would carry, and the History panel can delete entries that recorded one. A built-in scanner also flags anything that would become public through a public workspace or published documentation.
Redaction. Published documentation blanks secret variables, credentials in auth settings and headers such as Authorization, Cookie and X-Api-Key. Mock server call logs store those headers as [redacted].
Encrypted vault. The vault keeps secrets encrypted on your device. Each secret can be restricted to the domains it may be sent to, and scripts can use it only if you allow them to.
Trash and history. Deleted items go to a trash for 30 days, and collections keep version history, so mistakes can be undone.

How we protect the network

Because the web app sends requests from our servers, we guard against server-side request forgery (SSRF). Every request our servers send for you, including requests, collection runs, load tests, flows, monitors, protocol connections, OAuth 2.0 token requests and webhooks, refuses private, loopback, link-local, carrier-grade NAT and reserved addresses. Proxies you configure are checked and pinned to a public IP address. Webhook and alert deliveries are pinned to the checked address and never follow redirects. Timeouts, response sizes, concurrent runs and load-test sizes are capped.

The local bridge (swc bridge) lets the web app reach localhost without opening anything on your computer to the internet: the bridge connects out to swastik.codes with your API key and takes work only from your own signed-in sessions. No website can talk to it. It prints every request it runs, never reads files unless you start it with --allow-files, and requests pass through our server in memory only.

Scripts

Pre-request and test scripts run on our servers in an isolated JavaScript sandbox with time and memory limits. Scripts have no file system or process access, and network access from scripts (swc.sendRequest) goes through the same network safeguards as any other request.

Code that runs in your browser on behalf of someone else, such as a flow expression written by a teammate or a response visualizer, runs in a sandboxed frame with no access to your session, storage or our API. Markdown in descriptions, comments and published docs is cleaned with a strict allowlist before it is shown.

Transport and infrastructure

All traffic to swastik.codes and its subdomains is encrypted with HTTPS, and browsers are told to use HTTPS only (HSTS). Every page sends a strict Content Security Policy that runs only our own script files, blocks plugins and framing, and the site loads no third-party scripts or trackers. Outgoing webhooks are signed with HMAC-SHA256 so you can verify they came from us.

Reporting a vulnerability

If you believe you have found a security vulnerability in Swastik Codes, please tell us. Email support@swastik.codes with "Security" in the subject line, or use the contact form with the topic set to Security. Please include:

a description of the issue and its impact;
steps to reproduce it, with the URLs, requests or proof-of-concept involved;
your name or handle if you would like to be credited.

We will acknowledge your report within 3 working days, keep you updated while we investigate, and let you know when it is fixed.

Guidelines

When researching, please:

only test against your own account and data, or accounts you have explicit permission to use;
do not access, change or delete other users' data; if you encounter it by accident, stop and tell us;
do not run denial-of-service or load tests against our infrastructure, send spam, or use social engineering or physical attacks;
do not use the service to attack third-party systems (see the acceptable use policy);
give us reasonable time to fix the issue before disclosing it publicly.

If you follow these guidelines and act in good faith, we will not pursue legal action against you for your research, and we will work with you to understand and fix the problem. We do not currently run a paid bug bounty programme, but we are glad to credit researchers who want to be credited.

Out of scope

Reports that the web app's cloud proxy cannot reach localhost or private networks. This is intended; use the local bridge or the desktop app.
Missing security headers on pages that hold no sensitive data, without a demonstrated impact.
Rate-limit or brute-force findings that do not bypass the existing limits.
Vulnerabilities in third-party APIs you call through Swastik Codes; report those to their owners.