TL;DR: We store sensitive documents in private storage, grant access with short-lived links after authorization, isolate each user’s rows in the database, and log sensitive actions. We minimize data, secure our mobile apps, and give researchers a clear way to contact us.
Why security matters for credit dispute data
Credit reports and dispute letters contain information that can be exploited for identity theft and social engineering. Our security approach is simple: protect only what we need to collect, keep it only as long as it’s useful, and gate every access with strict authorization. The guiding principles are least privilege, defense-in-depth, and auditability.
Private storage with short-lived access
Dispute letters and supporting documents live in private object storage—not on public links. When a signed-in user requests a document, our API:
- Verifies identity and confirms the user owns the file
- Issues a time-limited, single-purpose link (minutes, not days), or securely streams the file
- Records the event for auditing
Links expire automatically. We can revoke them early and rotate keys without downtime.
Server-side authorization on every request
We never trust the client alone (web, iOS, or Android). The app calls our API, and the API enforces authorization every time—record reads, writes, and file downloads all require that the requester owns the resource.
What this means for you: screens only show your data, and accidental or malicious cross-account access is blocked at the server.
Database row-level isolation
We also enforce Row-Level Security (RLS) in our database. Even if a query were misused, RLS confines access to rows belonging to the authenticated user context. This is a second layer beneath our application checks.
Minimal data, minimal time
- We keep PII out of filenames and URLs and use non-guessable IDs.
- We store only what is required to deliver the product’s value.
- We apply retention windows so old artifacts (like past letter versions) don’t linger indefinitely.
Strong authentication and sessions
- Short-lived access tokens for users; elevated permissions require fresh authentication.
- Administrative access is protected by additional controls.
- We use rate limiting and anomaly detection on sensitive endpoints.
Secure handling in our mobile apps
Our iOS and Android builds don’t embed storage keys or direct file paths. The apps call our API, which performs all checks and returns only short-lived access. This keeps secrets server-side and aligns with store privacy requirements.
Responsible disclosure
We value the security research community. If you believe you’ve found a vulnerability, please contact us at security@better.report. We’ll acknowledge receipt promptly and keep you updated while we investigate and remediate.
Your role in staying safe
- Use a strong, unique password for your account.
- Keep your email secure—password resets arrive there.
- Don’t share temporary links; they’re designed for your session and expire quickly.
- Report suspicious messages that claim to be Better Report™.
What we won’t publish about our security
Transparency matters, but we won’t share implementation details that would aid attackers—such as internal URLs, storage bucket names, account IDs, schema names, or key rotation schedules. This post is intentionally high-level.