Protection built for sensitive ground truth
Weidenmap holds data about vulnerable people, so protection is part of the product, not a footnote. Here is exactly how it works - and, just as importantly, where the limits still are.
How the product protects data
Access is enforced on the server, on every read - never assumed from the UI.
- Strict multi-tenancy
- Each organization is its own tenant on its own subdomain; every request is checked against a verified membership. There is no cross-tenant access except the explicit, opt-in shared-response feature.
- Granular visibility, enforced server-side
- Five levels - private → group → org → response → public - are checked on every read. Public and cross-org surfaces receive sanitized projections with internal ids stripped, never the raw stored record.
- “Do no harm” controls
- Sensitive features can be marked Protected, which coarsens their location by deterministic grid-snapping - so repeated reads can’t be averaged back to the real point - for every audience outside the owning org. Per-field sensitivity tiers keep PII such as beneficiary details inside the org, or among response partners only, never on the public web.
- Passwordless authentication
- Magic-link sign-in means there are no passwords to leak. Sessions use HMAC-signed, HttpOnly cookies, and sign-in is rate-limited at the edge.
- Revocable share links
- Login-less share links are revocable and can be set to expire, and are stored only as a hash. Shared features pass through the same protection projection as the public map, and photos downloaded through a share link are scrubbed of EXIF/GPS metadata - so a Protected feature’s coarsened pin isn’t undermined by its photo.
- Compliance foundations
- A full audit log records security-relevant actions, and GDPR self-service export and account deletion are built in - authored content is anonymized rather than orphaned.
- AI image analysis is opt-in
- Image analysis is off by default. An admin enables it per organization; only then, and only when an editor runs it, is an image sent to Anthropic’s Claude. Leave it off and no images ever leave Weidenmap for analysis.
Running on the edge is a security story, not just a speed one
Weidenmap runs entirely on Cloudflare. That choice removes whole classes of exposure.
- No servers of our own to patch or expose
- The API runs in isolated edge sandboxes (Cloudflare Workers) - there is no fleet of long-lived servers to harden, patch, or leave open.
- No public database or storage endpoint
- The database (D1) and file storage (R2) have no public endpoint - they are reachable only through the app, and encrypted at rest. File downloads are always mediated by an auth check.
- Encrypted transport, always-on DDoS protection
- All traffic runs over TLS, behind Cloudflare’s always-on DDoS protection. Production and development run as fully isolated deployments.
Honest limitations
We keep a candid limitations list. For a humanitarian audience, naming these matters more than hiding them - and we’re working them down.
- No application-level end-to-end encryption yet.
- Image EXIF/GPS scrubbing covers share-link downloads (JPEG/PNG) - not yet other formats like WebP/HEIC, or stripping on upload.
- Location fuzzing is deterministic grid-snapping, not k-anonymity.
- No server-side session revocation yet.
- A map-pan bounding-box side channel exists on shared views.
What we don’t claim (yet)
Weidenmap does not currently hold SOC 2, ISO 27001, or HIPAA certification, and we don’t publish signed DPAs, a sub-processor list, or penetration-test results. We’d rather describe the architecture truthfully than imply a posture we haven’t earned. If your security review needs documentation we haven’t published here, get in touch and we’ll share what we have.