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)
• Encryption keys are rotated quarterly
• 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)

TOTP-based 2FA using RFC 6238. Compatible with any authenticator app. See Team Management for setup instructions and org-wide enforcement.

WebAuthn / passkeys

FIDO2-compliant WebAuthn support for hardware security keys and platform authenticators. Can be used as a second factor or as the sole authentication method (passwordless).

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 and Super 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 via the API (GET /api/v1/audit-logs).

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, penetration testing by third-party firm
• Planned: SOC 2 Type I audit (targeting Q3 2026), followed by Type II observation period

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.
• Not enabling 2FA for admin accounts. Admin accounts can manage cloud connections and user access. Protect them with 2FA at minimum.
• 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 a small number of senior engineers, requires MFA, and is logged. 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? SSO via SAML is on the roadmap. Currently, authentication is email/password + 2FA/WebAuthn.

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.
• Enable 2FA for all users, especially admins. Enforce it at the org level.
• 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.