Trust Center

StaleSweep only ever requests read-only access to your AWS environment, through a role you control and can revoke at any time. We never request write or delete permissions in your account.

Our approach is built on a few core principles:

• Least privilege by default — every credential and permission is scoped to what it actually needs, nothing broader.
• Defense in depth — network isolation, encryption, authentication, and application-layer controls are independent, overlapping layers, not a single point of failure.
• Fail closed, not open — misconfigurations and invalid requests are rejected, never silently allowed through.
• Transparency — we'd rather tell you plainly what we do and don't have than dress up gaps as strengths.

We do not currently hold SOC 2, ISO 27001, or other formal third-party certifications. We'd rather say that plainly than imply otherwise.

Our control environment already reflects many of the practices those frameworks require — encryption, access controls, monitoring, and audit trails — and formal certification (SOC 2 Type II is the natural next step) is on our roadmap as the company grows.

If your procurement process requires a completed security questionnaire, a signed DPA, or a conversation with our team, reach out to security@stalesweep.com — we'll work through it directly.

• Encrypted in transit. All traffic between your browser and our application is encrypted over HTTPS. Internal connections between our application and its data stores are also encrypted.
• Encrypted at rest. Customer data is encrypted at rest using industry-standard encryption.
• Credential handling. Database and infrastructure credentials are stored in a dedicated secrets management system — never in source code, configuration files, or logs.
• Data residency. StaleSweep is currently a single-region deployment hosted in the United States. We do not currently offer data residency in other regions.
• Payment data. StaleSweep never stores, processes, or transmits raw payment card data. All billing is handled by Stripe, a PCI DSS Level 1 certified payment processor — the full card number never reaches our servers.

Authentication

• OAuth 2.0 sign-in via Google and Microsoft, using current security best practices for the authorization flow.
• SAML SSO for enterprise accounts, configurable per organization. If your identity provider enforces MFA, conditional access, or device compliance, those policies apply automatically to StaleSweep logins.
• Authentication is delegated entirely to your identity provider — Google, Microsoft, or your SAML IdP — so your own password, MFA, and conditional-access policies govern every sign-in. StaleSweep stores no passwords of its own.

Sessions

• Session tokens are short-lived, signed, and delivered exclusively as cookies that are inaccessible to JavaScript and never stored in browser local storage.
• Sessions can be instantly revoked, independent of a token's natural expiry.
• Our refresh mechanism is protected against token replay — reuse of a token after it has already been rotated immediately revokes the associated session, rather than being silently accepted.
• Customers can view and revoke their own active sessions (login method, general location info, device) directly in the app.

• Hosting. StaleSweep runs on Amazon Web Services (AWS) infrastructure. Application servers are not directly reachable from the internet — all traffic passes through a managed load-balancing and edge layer.
• Network isolation. Databases and caches are on private, internal networks with no direct path from the public internet.
• Edge protection. Our infrastructure sits behind a content delivery and web-traffic filtering layer that helps mitigate abusive and malicious traffic before it reaches our application.
• Least-privilege infrastructure access. Internal service permissions are scoped to what each component actually needs to operate.
• Cross-account scanning access. The role StaleSweep assumes in your AWS account is read-only and gated by a unique identifier specific to your account — it can be revoked at any time from your own AWS console, and the exact permissions requested are visible in the CloudFormation template before you ever deploy it.
• Monitoring. We maintain centralized logging of application and infrastructure activity to support security monitoring and incident investigation. Logging is scoped to avoid capturing sensitive customer data or query contents.
• Backups. Automated backups run on a regular schedule with defined retention, and a safeguard snapshot is taken before any planned data deletion.

• Input validation. Every API request is validated against a strict, typed schema before it reaches business logic — malformed or unexpected input is rejected at the boundary.
• Injection protection. All database access is parameterized through our data access layer. Raw, string-built queries are not used anywhere in the codebase.
• Rate limiting. All endpoints are rate-limited per client, with tighter limits on sensitive operations such as authentication.
• Secure headers. Our application sends a full set of modern browser security headers, covering protections against content-type sniffing, clickjacking, and enforced HTTPS.
• CSRF protection. State-changing requests are validated to ensure they originate from our own application.
• Content Security Policy. Our web application enforces a strict content security policy to reduce the risk of cross-site scripting and code injection — you can inspect it yourself in your browser's developer tools on any page.
• XSS protection. We rely on our frontend framework's built-in output encoding and do not render untrusted content as raw HTML.
• Webhook integrity. Incoming events from our payment processor are cryptographically verified before being processed, and duplicate events are safely ignored.
• Dependency security. We continuously scan our dependencies for known vulnerabilities as part of our build process and address high-severity findings promptly.
• Fail-safe configuration. Our systems are designed to fail safely — for example, refusing to start if required security configuration is missing, rather than falling back to an insecure default.

• Unexpected application errors are logged internally with full detail for investigation, while the response returned to the client never reveals internal implementation details.
• We maintain audit trails of billing activity and account session activity to support security investigations.

If we identify or are notified of a security incident affecting customer data, we will investigate promptly and notify affected customers in accordance with applicable law and our contractual commitments.

For enterprise customers, specific incident notification terms can be included in a signed agreement.

Found a security issue? Please report it privately, not in public: security@stalesweep.com