Security
Version 1.1 · Effective: 14 August 2026
Version 1.1 clarifies that Cloudflare stores and delivers customer content and derived search indexes, while Neon stores authoritative relational application data. The effective date above governs the transition for existing customers following 14 days' notice.
| Service | display.dev — gated artifact publishing engine |
| Provider | Displaydev OÜ, Ankru 8-23, Tallinn, 11713, Estonia |
| Data location | Primary customer content and application records are stored using Cloudflare and Neon infrastructure. PostHog is in the EU; Neon, Fly.io, Postmark, and Stripe are in the US; Cloudflare is global (EU primary where available). |
| Transfer mechanism | EU Standard Contractual Clauses (SCCs) for all non-EU sub-processors |
| Report a vulnerability | report@display.dev |
| General security contact | privacy@display.dev |
For the full list of sub-processors and the data each handles, see the Privacy Policy §5. For the contractual terms that govern processing of personal data on your behalf, see the Data Processing Agreement.
Scripts in artifacts run with normal browser capabilities
Artifacts on *.dsp.so are real HTML. Any JavaScript, styles, or embedded resources the publisher included reach the viewer's browser unchanged. Authentication controls who can view an artifact; it doesn't sandbox the artifact's scripts from viewers inside the same organisation. A publisher inside your organisation could write an artifact that exfiltrates its contents to an external endpoint — the same risk as any insider with read access to your company documents. It isn't specific to display.dev.
The view-token cookie is scoped to the exact host that issued it, so a script on acme.dsp.so can't replay cookies on beta.dsp.so. Every publish is attributed in the audit log, so any abuse traces back to an identified publisher. That doesn't eliminate the risk — preventing JavaScript would make the product useless for the reports, dashboards, and interactive explainers it exists to host.
For questions or to request a stricter publishing mode, email privacy@display.dev.
Data location and transfer
| Data | Primary location | Transfer mechanism |
|---|---|---|
| Authoritative relational application data: customer accounts, organisations, usage events, billing records, and audit logs | Neon — United States | EU SCCs |
| Customer-content storage, delivery, caching, and derived search indexes | Cloudflare — Global (EU primary where available) | EU SCCs |
| Product analytics | PostHog — EU (eu.posthog.com) | No third-country transfer |
| Application runtime | Fly.io — Ashburn, VA (US) | EU SCCs |
| Transactional email | Postmark — United States | EU SCCs |
| Payment processing | Stripe — United States | EU SCCs |
Encryption
In transit. All traffic to display.dev, dsp.so, and app.display.dev is served over TLS 1.2 or higher. HSTS is enabled on our own origins.
At rest. Primary customer content and application records are stored using Cloudflare and Neon infrastructure. Cloudflare stores artifact content, delivery/cache data, short-lived tokens, and derived search indexes; Neon stores authoritative relational application data. Each vendor applies encryption at rest by default, as documented in its security materials. We run no self-managed persistent storage.
Access controls
- Organisation scoping. Every artifact and every API operation is scoped to exactly one organisation. Cross-org reads are blocked at the data layer, not just at the API layer.
- API keys. Each key is bound to a user or an organisation and carries a fixed scope. Keys are hashed at rest; the plaintext is only visible at creation. Revocation is immediate.
- Authentication. Account sign-in uses email one-time codes (OTP) by default, with Google or Microsoft SSO available on paid plans. Sessions are short-lived and refreshed on activity.
- Artifact access. Private artifacts are gated behind viewer authentication via one-time code. View tokens are short-lived (≤ 1 hour) and scoped to a single artifact.
- Production access. Only named members of the engineering team hold production credentials.
Incident response
If we become aware of a security incident that affects Customer Content or personal data, we will:
- Notify affected customers without undue delay, and in any event within 72 hours where notification is required under GDPR Art. 33.
- Provide a description of the incident, the data categories affected, the likely consequences, and the measures taken or proposed.
- Publish a post-incident summary after remediation.
Report a suspected incident to privacy@display.dev.
Vulnerability reporting
We welcome vulnerability reports. Send them to report@display.dev with:
- A description of the vulnerability and the affected surface (display.dev, dsp.so, app.display.dev, API, CLI, MCP).
- Steps to reproduce.
- An assessment of the impact.
We respond to every vulnerability report. Confirmed high-severity issues are prioritised over everything else. We don't currently operate a paid bug bounty programme.
What we do not do
- We do not sell, share, or licence personal data to third parties.
- We do not use Customer Content to train, fine-tune, or evaluate any AI or machine-learning model. See Terms of Service §5.6.
- We do not run third-party advertising pixels, social-media pixels, or cross-site trackers on any of our surfaces.
- We do not load third-party client-side analytics on the public artifact origin (dsp.so). See Cookie Policy §8.
Planned work
We do not hold a SOC 2 report today. As our customer base grows we will publish timelines for SOC 2 Type I and Type II. Customers with a formal security-review requirement can request a CAIQ or SIG questionnaire response from privacy@display.dev.
Contact
- Vulnerability reports: report@display.dev
- Security incidents: privacy@display.dev
- Privacy inquiries: privacy@display.dev
Displaydev OÜ Ankru 8-23, Tallinn, 11713, Estonia