Hi everyone,
I’ve developed DenunzIA, an open-source platform designed for totally anonymous citizen whistleblowing and ethical intelligence. Given the sensitive nature of the data it's meant to handle, security and anonymity are the top priorities.
The project is currently in a "ready-for-audit" state, and I would love for the community to tear it apart and help me find any potential vulnerabilities.
Technical Stack & Security Implementation:
End-to-End Encryption (E2EE): Using RSA-4096 to protect whistleblower identities.
Backend: Node.js with a focus on secure API endpoints.
Database: PostgreSQL for robust and structured data persistence.
Infrastructure: Fully Dockerized for isolated and reproducible deployments.
Frontend: React/TypeScript with client-side encryption.
What I’m looking for:
Code Audit: Specifically regarding the encryption/decryption flow in services/cryptoService.ts.
Architecture Review: PostgreSQL schema and data isolation.
Vulnerability Assessment: Any potential for leakages in the Docker configuration or API.
The goal is to provide a safe tool for social transparency. Any feedback, PRs, or "issues" reported on GitHub would be greatly appreciated.
Repository: https://github.com/denunciasiie/denunzia-v1
Thanks in advance for your time and expertise!
Top comments (1)
Really cool project — anonymous reporting is one of those problem spaces where getting the crypto right is table stakes but getting the UX right is what determines whether people actually use it.
A few thoughts on the security side:
RSA-4096 for E2EE is solid, but consider whether you need forward secrecy. If the server's private key is ever compromised, can historical reports be decrypted? A hybrid approach (ephemeral ECDH + AES for session encryption, RSA for key transport) would give you PFS.
Docker isolation — make sure your containers run as non-root and your Postgres container isn't exposed on the host network. I've audited too many Dockerized apps where the database port was accidentally bound to 0.0.0.0.
Metadata leakage is usually the bigger threat than content leakage. Even with E2EE, if your server logs IP addresses, timestamps, and request patterns, an adversary can correlate reports to reporters. Consider Tor-friendly deployment and stripping request metadata at the reverse proxy layer.
The geolocation angle — if reports are tied to physical incidents, consider how location data is handled. Some anonymous reporting tools like icemap.app let users pin incidents to a map without any identity exposure at all — no accounts, no cookies, just "here's what happened at this coordinate." That zero-friction approach might be worth studying for your UX.
Will check out the repo and look at the cryptoService.ts flow. Good luck with the audit! 🔒