Xplorr Security

Xplorr Security

This page covers how Xplorr handles your data, what access it requires, and the security controls in place to protect your organization.

Credential encryption

Cloud credentials (IAM role ARNs, Azure service principal secrets, GCP service account keys) are encrypted at rest using AES-256-GCM. The encryption key is managed separately from the application database — a compromised database dump does not expose your credentials.

Key details:

• Each credential is encrypted with a unique initialization vector (IV)
• One encryption key is held outside the database, in the deployment’s secret store; it is not rotated on a schedule today
• Credentials are decrypted only at the moment of use (during a sync) and are never held in plaintext in memory longer than the sync operation

Read-only access

Xplorr only requests read-only permissions to your cloud accounts. Here’s exactly what we can and cannot do:

What Xplorr can read

• Billing and cost data (Cost Explorer, cost management exports, BigQuery billing)
• Resource inventory (instance types, counts, regions — used for rightsizing recommendations)
• Tag metadata (for cost allocation)
• Reservation and savings plan details (for coverage analysis)

What Xplorr cannot do

• Create, modify, or delete any cloud resource
• Access your application data, databases, or storage contents
• Read secrets, environment variables, or application configurations
• Make purchases (reserved instances, savings plans, marketplace subscriptions)
• Modify IAM policies or security groups

If you’re using the recommended IAM policies from the Connect AWS guide, the permissions are scoped to ce:Get*, ce:Describe*, ec2:Describe*, and organizations:ListAccounts. No write actions.

Authentication

JWT + refresh tokens

Xplorr uses short-lived JWT access tokens (15-minute expiry) paired with longer-lived refresh tokens (7-day expiry). The flow:

1. User logs in with email/password (+ 2FA if enabled)
2. Server issues an access token and a refresh token
3. The access token is sent with every API request
4. When the access token expires, the client uses the refresh token to get a new one
5. If the refresh token is expired or revoked, the user must log in again

Refresh tokens are stored as HTTP-only secure cookies — not accessible to JavaScript.

Two-factor authentication (2FA)

2FA is required for every organization. Every password sign-in, including choosing an organization, accepting an invitation, and verifying an email address, asks for a second factor: a TOTP code (RFC 6238, compatible with any authenticator app) or a security key or passkey. It isn’t an admin-configurable setting; it applies from the day an account is created, and anyone without a factor set up is walked through enrolling one at their next sign-in rather than locked out.

Signing in through SAML SSO is exempt from this prompt, since your identity provider handles multi-factor authentication on its side. The exemption follows the sign-in method, not the account: a SAML account that tries a password sign-in instead of going through SSO, and has no factor of its own enrolled, is refused with USE_SSO and pointed at SSO sign-in rather than left at a dead end. See Team Management for setup instructions.

Security keys and passkeys (WebAuthn)

Hardware security keys such as a YubiKey, the built in authenticator of a device (Touch ID, Face ID, Windows Hello) and passkeys from a password manager or phone can all be registered as a second factor. They are used after the password, not instead of it.

• Each person can register up to 10 keys, and any one of them completes a sign in.
• When adding a key you choose Security key, This device or Passkey from a password manager or phone, so the browser asks for the right kind.
• Mandatory enrolment offers a backup key right after the first one.
• Keys can be renamed. The only remaining second factor (the last key with no authenticator app, or the authenticator app with no key) cannot be removed.

See Security keys and passkeys for the steps, including registering two YubiKeys.

Single sign-on (SAML)

Enterprise organizations can set up SAML 2.0 single sign-on: SAML sign in, auto-provisioning of new users on first login, and requiring SSO for everyone. See Team Management for setting it up.

A domain does nothing until it is verified. After an admin enters an email domain for SSO, Xplorr publishes a token; the admin adds it to the domain’s DNS as a TXT record at _xplorr-verify.<domain> and clicks Verify in the console. Until that check passes:

• Signing in with an email at that domain never routes to SSO.
• SAML sign in for that domain is refused, even with a correctly configured identity provider.
• Auto-provisioning does not create accounts for that domain.
• “Require SSO for all” has no effect.

This stops a domain from being claimed for SSO by anyone who has not proven they control it. Only one organization can hold a verified domain at a time, and changing the domain on file resets verification.

Xplorr staff accounts cannot sign in through your organization’s SSO, verified or not.

Account lockout

Failed login attempts trigger progressive lockout:

Failed attempts	Lockout duration
5	1 minute
10	5 minutes
15	15 minutes
20+	1 hour

The lockout counter resets after a successful login. Lockout applies per-account, not per-IP — so an attacker can’t bypass it by switching IP addresses.

During lockout, the user sees a message indicating when they can try again. Admins can manually unlock a user from Settings → Team.

Rate limiting

API endpoints are rate-limited to prevent abuse:

Endpoint category	Limit
Authentication (login, token refresh)	20 requests/minute per IP
Read endpoints (dashboards, reports, costs)	100 requests/minute per user
Write endpoints (create budget, update settings)	30 requests/minute per user
Report generation	5 requests/minute per user
Data export	10 requests/minute per user

Rate limit headers are included in every response:

X-RateLimit-Limit: 100
X-RateLimit-Remaining: 87
X-RateLimit-Reset: 1710756000

When the limit is exceeded, the API returns 429 Too Many Requests with a Retry-After header.

Audit logging

Every significant action in Xplorr is logged:

• Authentication events — login, logout, failed login, 2FA setup, password change
• User management — invite sent, role changed, user removed
• Cloud account changes — account connected, disconnected, credentials updated
• Settings changes — budget created/modified, alert rule created/modified, notification preferences changed
• Data access — report generated, data exported

Audit logs are available to Admins at Settings → Audit Log. Each entry includes:

• Timestamp (UTC)
• User who performed the action
• Action type
• Affected resource
• IP address
• User agent

Logs are retained for 90 days. For longer retention, export them as CSV from the audit log page. See Audit Logs.

Sign-in history

Every login attempt against your account is recorded: the outcome (success, wrong password, wrong second factor, rate limited, unverified), the method (password, TOTP, passkey, SSO), IP address, browser and country. Xplorr staff can see this history when helping with an account issue. It is kept for 90 days, the same as the audit log.

Infrastructure security

• Transport encryption — all traffic is encrypted with TLS 1.2+ (TLS 1.3 preferred). HSTS is enabled.
• Database — PostgreSQL with encryption at rest. Backups are encrypted with AES-256.
• Secrets management — application secrets are stored in environment variables, not in code or config files.
• Dependency scanning — automated vulnerability scanning on every build.
• Container security — application containers run as non-root users with read-only filesystems.

SOC 2 roadmap

Xplorr is working toward SOC 2 Type II certification. Current status:

• Completed: Access controls, encryption at rest and in transit, audit logging, incident response procedures
• In progress: Formal security policies documentation
• Planned: Penetration testing by a third-party firm, and a SOC 2 audit targeting Q2 2027

If you need a security questionnaire completed or have specific compliance requirements, contact [email protected].

Common mistakes

• Granting Xplorr more permissions than needed. Use the minimal IAM policy from the setup guide. Don’t attach AdministratorAccess or PowerUserAccess to the Xplorr role.
• Sharing API tokens. Each user should have their own API token. Shared tokens make audit logs useless because you can’t attribute actions to individuals.

FAQ

Does Xplorr store my cloud credentials? Yes, encrypted with AES-256-GCM. For AWS, we store the role ARN (the actual assume-role operation uses temporary STS credentials). For Azure and GCP, we store the service principal or service account credentials, encrypted.

Can Xplorr employees access my data? Production data access is restricted to platform staff, a small list of Xplorr accounts kept separate from any customer organization, each bound to one specific account and required to use a second factor. Staff access is logged, and staff cannot sign in through your organization’s SSO. Access is only used for debugging issues at your request.

What happens if Xplorr has a security incident? We will notify affected customers within 72 hours with details of the incident, the data affected, and remediation steps. Contact [email protected] for our full incident response policy.

Can I use SSO/SAML? Yes, for Enterprise organizations. See Single sign-on (SAML) above; a domain does nothing until you verify you own it.

Where is my data stored? Xplorr runs on infrastructure in the US. If you have data residency requirements, contact us to discuss options.

Key takeaways

• Xplorr only has read-only access to your cloud accounts. No write permissions, no access to application data.
• Credentials are encrypted at rest with AES-256-GCM and decrypted only during sync operations.
• 2FA is required for every account by default; only SSO sign-in is exempt.
• Review audit logs periodically to ensure no unexpected access patterns.
• SOC 2 Type II certification is in progress — reach out if you need compliance documentation now.