Securing your app
This section documents the controls Axowl operates on your behalf, and the ones you configure yourself. Each item below maps to a mechanism that exists in the product today — where a control is partly implemented or opt-in, it says so, because a security page that overstates coverage is worse than no page at all.
Transport & browser hardening
Section titled “Transport & browser hardening”Every API response carries a fixed set of hardening headers (SecurityHeadersMiddleware):
| Header | Value | What it stops |
|---|---|---|
X-Content-Type-Options | nosniff | MIME-sniffing a response into a script |
X-Frame-Options | DENY | Clickjacking via framing |
Referrer-Policy | strict-origin-when-cross-origin | Leaking paths/tokens in Referer |
Permissions-Policy | camera=(), microphone=(), geolocation=() | Silent device access |
Strict-Transport-Security | max-age=31536000; includeSubDomains (HTTPS only) | Downgrade to HTTP |
TLS terminates at the edge; application containers speak HTTP only inside the private network.
Session security
Section titled “Session security”Cookies. Session cookies are HttpOnly (JavaScript cannot read them), Secure over
HTTPS, and SameSite=Lax. Because HttpOnly keeps the token out of reach of page scripts,
a script injection cannot exfiltrate a session.
CSRF. State-changing requests authenticated by cookie must echo a double-submit token
(X-CSRF-Token) that matches the axowl_csrf cookie; a mismatch is rejected with 403.
Requests that authenticate by Authorization: Bearer, API key, or webhook signature are not
cookie-driven and are verified by their own credential instead.
Session policy (per organization). Under Organization → Settings → Security Policy you set maximum session duration, idle timeout, and the number of concurrent sessions per member. The organization maximum cannot exceed the platform ceiling.
Step-up re-authentication. Consequential actions — deleting an organization, transferring ownership, accepting a transfer, impersonation — require a fresh passkey assertion at the moment of the action, not merely a valid session. Axowl calls this stamping your seal. A stolen or forgotten-open session is not enough to perform them.
Authentication
Section titled “Authentication”Passkeys (FIDO2/WebAuthn) are the primary factor; magic links, social providers, and enterprise SSO (SAML 2.0 and OIDC) are also supported. Passwords are not the default path.
Key binding. You choose where a member’s passkey private key may live: synced (roams across the member’s own devices via platform keychains) or device-bound (never exportable, strongest reclaim guarantee). Plaintext cloud password managers are refused regardless of the setting.
Device trust
Section titled “Device trust”Device policy sets the floor for which machines may reach your workspace:
- Open — any device is trusted on first successful passkey login (BYOD on).
- Hybrid — BYOD stays on, but the organization can pre-register company-owned devices and tell them apart; a device other than the member’s assigned one needs admin approval.
- Fortress — only pre-registered devices are admitted; unrecognized devices are blocked.
The mode also determines how a new device login is handled (allow / require approval / block), so the two settings cannot contradict each other.
Shared-device detection. By default a device is expected to belong to one member. If a different member signs in on the same device, admins are alerted and the user sees a banner. This detection is browser-based and therefore best-effort — it can be evaded by clearing cookies or switching browsers. Identity itself is always proven by the passkey, not by the device signal. Enforced, tamper-resistant device binding is a separate add-on.
Access control
Section titled “Access control”Access is evaluated on two independent axes. Membership answers “is this person in this organization”; entitlement answers “may this person perform this action”. A role is a named bundle of scopes, and scopes are checked per action rather than inferred from a title. Billing is carved out to the Owner and is not granted implicitly by an admin role.
Tenant isolation
Section titled “Tenant isolation”Organization-scoped requests resolve the tenant before the handler runs: the caller must be an active member of the organization named in the URL, otherwise the request is rejected with 401 (not signed in) or 403 (not a member). Repository queries for organization-owned entities apply the resolved tenant as a mandatory filter, and refuse to run when no tenant context is present — isolation fails closed rather than returning a broader result set.
Restricting who can reach your organization
Section titled “Restricting who can reach your organization”Two organization-level controls narrow the surface before authentication succeeds:
- Allowed email domains — members must present an email in your domain list to join or to register a device.
- Country access policy — logins from outside your allowed regions are allowed-and-logged, held for admin approval, or blocked outright, as you choose. The owner’s country is always allowed. Temporary grants cover business travel without weakening the standing policy.
Bot and abuse resistance
Section titled “Bot and abuse resistance”Public sign-up style endpoints are gated by Cloudflare Turnstile. When the CAPTCHA secret is not configured, those endpoints refuse the request rather than accepting it unverified — a missing control is treated as a closed door, not an open one.
Secrets you hold
Section titled “Secrets you hold”API keys, plugin tokens, and webhook secrets are stored as hashes; the plaintext value is shown exactly once, at creation, and cannot be retrieved afterwards. Each can be rotated or revoked independently, and rotation is recorded. Rotating the organization signing key invalidates outstanding signed permits, so plugins must refresh their cached public key.
Your third-party credentials (SAP, AWS, on-premise systems) are never sent to Axowl. A plugin token proves “this caller is your plugin” and grants no access to your cloud resources.
Tamper-evident audit trail
Section titled “Tamper-evident audit trail”Consequential records are hash-chained and sealed, so modification is detectable rather than merely discouraged — including modification made directly in the database. Verification is independent: a record can be re-hashed and checked against its stored seal without trusting the application that wrote it.
Reporting a vulnerability
Section titled “Reporting a vulnerability”If you believe you have found a security issue, email security@axowl.com with enough detail to reproduce it. Please do not disclose publicly until we have responded. We do not pursue legal action against good-faith research that avoids privacy violations, service degradation, and access to data beyond what is needed to demonstrate the issue.