Penetration Test Summary
1. What Was Tested
We build a security platform, so we hold our own platform to the standard we help customers meet. In August 2026 our own security engineers put the platform through an external penetration test and vulnerability assessment, operating from an outside attacker's position with the same industry-standard offensive tooling a real attacker would use.
| Assessment date | 23 August 2026 |
|---|---|
| Performed by | SimpleSecurity's own security engineers, operating from an external attacker's position — an honest self-assessment, published as such |
| Methodology | Automated scanning plus targeted manual testing, with coverage aligned to the OWASP Top 10 vulnerability classes |
| Scope | The public website, the customer application, and the backend API and identity services hosted in AWS Stockholm (eu-north-1) |
| Type | External, grey-box, non-destructive — no denial-of-service, no password brute-forcing, no data extraction |
| Coverage | Seven parallel workstreams: reconnaissance and DNS, transport encryption, HTTP security headers and web vulnerability scanning, content and storage exposure, API and authenticated backend testing, authentication and session-token security, and email and DNS security |
| Overall risk rating | Low |
The sections below describe what was attempted and what happened. We have deliberately written this in plain language rather than tool output, and we have left out the low-level technical detail that would only be useful to somebody attacking the platform.
2. Keeping Your Data Separate
For a multi-tenant platform this is the finding that matters most: can one customer reach another customer's data? The assessment attacked that boundary directly.
- Identifier manipulation was rejectedRequests were replayed with other customers' record identifiers, fabricated identifiers, sequential guesses, malformed values, and path-traversal attempts. All were refused.
- Tenant is decided by the server, not the clientAttempts to override the tenant through request parameters or custom headers had no effect. Which organisation you belong to is resolved from your cryptographically verified session and cannot be influenced by anything the browser sends.
- No cross-tenant leakage was observedNo request returned data belonging to another organisation.
- Permission checks fail closedAttempts to reach endpoints using unexpected HTTP methods were rejected at the gateway, before reaching application code.
3. Authentication & Sessions
Session tokens were subjected to a full battery of forgery and tampering techniques — removing the signature, downgrading the signing algorithm, substituting keys, editing the identity and permission claims inside the token, and replaying expired tokens. Every attempt was rejected.
- Permissions are never taken from the tokenWhat you are allowed to do is looked up on the server for each request, not read from a value the client could edit.
- Account creation is controlledSelf-service sign-up is disabled at the identity-provider level, not merely hidden in the interface.
- No account enumerationThe login flow does not reveal whether an email address is registered, so it cannot be used to harvest a list of our customers.
- Automated abuse protectionA rate-limiting control engages against high-volume traffic from a single source, and was confirmed to block during testing.
4. Encryption
All customer traffic is encrypted in transit with TLS 1.2 or 1.3, and all stored data is encrypted at rest with AES-256.
Connections use forward secrecy, valid certificates, and HSTS preloading — browsers refuse to connect to us over an unencrypted channel. Older protocol versions are not accepted on any host that serves customer traffic.
5. Common Web Attacks
The assessment swept the platform for the standard classes of web vulnerability using automated scanners with roughly 6,600 detection templates, plus targeted manual testing. No SQL injection, command injection, cross-site scripting, cross-site request forgery, insecure direct object references, or cross-origin misconfigurations were found. Input is validated on the server, and error responses do not leak internal detail.
Browser-side protections were confirmed in place across the site: a strict Content Security Policy, clickjacking and MIME-sniffing protections, a restrictive referrer policy, and cross-origin isolation headers — including on error responses, which are a commonly missed gap.
6. Email Impersonation
Phishing that impersonates a vendor is one of the most common ways an attacker reaches that vendor's customers. Our domain is protected by the full set of email authentication standards, all verified during the assessment:
- SPF and DKIMOnly our authorised mail systems can send as our domain, and every message is cryptographically signed.
- DMARC at the strictest settingOur policy is
p=reject. A forged email claiming to come from us is refused outright by receiving mail systems — not merely filed as spam. - MTA-STS in enforce modeMail sent to us must travel over a verified encrypted connection. An attacker on the network cannot force a downgrade to plain text.
- DNSSEC and CAAOur DNS records are cryptographically signed against tampering, and only named certificate authorities are permitted to issue certificates for our domain.
7. Exposed Data & Secrets
The assessment searched for the mistakes that most often cause breaches: exposed source-code repositories, configuration and backup files, hard-coded credentials in browser JavaScript, and publicly readable cloud storage. None were found. Our internal staff console is not part of the public application, and no internal hostnames or addresses are shipped to browsers.
8. Findings 1 Low · 1 Info
No assessment worth publishing finds nothing at all. This one raised two low-impact findings — one Low severity, one informational — both reviewed and accepted, with the reasoning stated here rather than hidden.
| Finding | Severity | Status |
|---|---|---|
| Older encryption protocols accepted on a default AWS hostname that carries no customer traffic | Low | Accepted — platform limitation |
| Cloud provider visible in HTTP response headers | Info | Accepted — cosmetic |
The one Low-severity item concerns a default AWS hostname that sits behind our API. That hostname still accepts older encryption protocols, because encryption is terminated by shared Amazon infrastructure before requests reach us — it is not a setting we can change. It carries no customer traffic and refuses every request it receives. All real traffic runs over our own domain, which enforces modern encryption only. We have accepted this as a platform limitation and documented it rather than quietly dropping it from the report.
The informational item is a cosmetic disclosure of the cloud provider in HTTP response headers, which is standard for this architecture and of negligible value to an attacker.
9. Scope & Limitations
We would rather be straight with you about what this assessment does and does not prove.
Testing was external, time-boxed, and non-destructive. No denial-of-service or password brute-forcing was performed, injection tooling ran at low-risk settings without extracting data, and write operations were exercised only through a sandboxed demo account. Third-party services outside our control were excluded.
A clean result for a given technique means no issue was observed during the test window — not a mathematical guarantee that none exists. This report reflects the state of the platform on 23 August 2026. The detailed technical findings, tooling output, and evidence files remain confidential; they are available to customers and prospects under NDA as part of a vendor-risk review.
10. Ongoing Commitment
Security is continuous, not a one-time certificate.
We re-test after significant changes, remediate findings promptly, and publish what we find.
We also welcome outside security research. We publish a security.txt with a security contact, and we credit researchers who report issues to us on our hall of fame. If you have questions about our security practices, or need documentation for a vendor-risk review, contact us at security@simplesecurity.se.