Security and data: what we read, what we store
For teams doing a security review, we spell out which data WAM accesses and what it does not store.
- AES-256-GCM encrypted secrets
- Row-level security (RLS) isolation
- HttpOnly + SameSite=Strict sessions
- Signed webhooks (HMAC)
- SSRF-protected monitoring
Security architecture
Where data comes in, how it's separated and how it's protected — in diagrams.
What we read — and what we never do
Each integration reads only the narrowest data needed. Items in the right column are never accessed under any condition.
Read
- Repo name, visibility, default branch
- Latest commit summary (first line, author, date)
- Deployment status
Never read
- File contents
- Secrets
Read
- Zones, DNS records, SSL mode
Never read
- Changes to your settings (a read-only token is recommended)
Read
- Aggregate metrics: users, sessions, page views
Never read
- Individual visitor data
Read
- Result: status, duration, size
Never read
- The backup file and its contents
Read
- Card brand and last four digits
Never read
- Card number (held by the payment provider)
Customers can't see each other
The organization ID comes only from the signed session token — never from the URL or request body. Separation is enforced in the database itself.
An organization can't query another's rows
Secrets are stored encrypted
API tokens and similar secrets are encrypted on write and never returned to the UI or in responses.
- Token enteredCloudflare, GitHub, Google…
- Encrypted with AES-256-GCMKey-version prefix (v1:), ready for rotation
- Stored encryptedNever shown in the UI or API responses
Session security
A short-lived access token lives in memory; the refresh token sits in a cookie the browser's scripts can't read.
Monitoring requests leave safely
Every check against your sites goes through one hardened client; requests into WAM's own internal network are blocked.
- 1Hostname is resolvedTarget IP is determined
- 2IP block list is checkedPrivate and internal ranges are rejected
- 3Connect to the resolved IPDefends against DNS rebinding
- 4Ports 80 and 443 onlyOther ports are rejected
- 5Redirects are re-checkedAt most 5; same check at every hop
- 6Response size is capped10 s timeout
Blocked ranges
Retention periods
Data is kept as long as it's useful, then deleted.
- Detailed resultsdays
- Hourly summaries90 days
- Daily summaries13 months
- Event history13 months
- Audit logs2 years
Support access
By default our support team can only read an organization.
Read-only access
Default; 30 minutes, not renewable
Write mode
Only with a written justification, 15 minutes
Audit trail
Every action is written to the organization's log
Detailed explanation
The first sentence under each heading is the summary; open it for the detail.
Your source code
WAM does not store or copy source code.
Details
The GitHub App is installed with these permissions: Metadata (read), Contents (read — technically required only for the commit list and push events), Deployments (read) and Actions (read). Data read and stored: repo name, visibility, default branch, language, last commit summary (first line of the message, author, date), daily commit counts and deployment status. File contents are not fetched. For Azure DevOps a read-only scoped access key is used and the same class of data is read. You can remove the installation from GitHub or Azure DevOps at any time.
Google Analytics
Only a read-only analytics permission is requested.
Details
Stored data: aggregate metrics such as users, sessions, page views and engagement. Individual visitor data is not read. You can revoke access from your Google account at any time.
Cloudflare
With your token, zones, DNS records and SSL mode are read.
Details
We recommend a read-only token; WAM does not change your Cloudflare settings.
Secrets
API tokens and similar secrets are stored with AES-256-GCM encryption and are never shown back in the UI or responses.
Details
Card details are not stored in WAM; they stay with the payment provider and only the card brand and last four digits reach us.
Data isolation
Each organization's data is separated at the database level with row-level security (RLS); one organization cannot query another's data.
Details
The organization identity comes only from the signed session token, never from the URL or request body.
Authentication
Passwords are stored with a strong hashing algorithm.
Details
Session renewal tokens change on every use; if theft is detected the session family is revoked. Failed sign-in attempts are rate limited.
Support access
Support access to an organization is read-only by default; write access can be enabled only with a stated reason, for a short time, and every action is written to the audit log.
Retention
Detailed monitoring results are kept for days, hourly summaries for 90 days, daily summaries for 13 months, event history for 13 months and audit records for 2 years.
Details
See the Privacy Policy for details.
Our monitoring requests
Checks against your sites come from a fixed user agent and published IP addresses; you can allowlist them in your firewall (Probe IPs page).
Reporting a vulnerability
If you find a security issue, write to the contact address below; we value responsible disclosure and respond as quickly as we can.
Found a vulnerability?
We value responsible disclosure and reply as soon as possible.