--- title: Security — Display.dev description: How display.dev handles artifact scripts, authentication boundaries, and the trust posture customers should understand before publishing. noindex: true --- # Security **Version 1.0 · Effective: 27 April 2026** | | | | ---------------------------- | ------------------------------------------------------------------------------ | | **Service** | display.dev — gated artifact publishing engine | | **Provider** | Displaydev OÜ, Ankru 8-23, Tallinn, 11713, Estonia | | **Data location** | EU (PostHog), US (Neon, Fly.io, Postmark, Stripe), global (Cloudflare R2 + KV) | | **Transfer mechanism** | EU Standard Contractual Clauses (SCCs) for all non-EU sub-processors | | **Report a vulnerability** | [report@display.dev](mailto:report@display.dev) | | **General security contact** | [privacy@display.dev](mailto:privacy@display.dev) | For the full list of sub-processors and the data each handles, see the [Privacy Policy](/privacy) §5. For the contractual terms that govern processing of personal data on your behalf, see the [Data Processing Agreement](/dpa). --- ## 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](mailto:privacy@display.dev). --- ## Data location and transfer | Data | Primary location | Transfer mechanism | | --------------------------------------------------------------------------- | ------------------------------- | ------------------------- | | Customer accounts, organisations, usage events, billing records, audit logs | Neon — United States | EU SCCs | | Customer artifacts (HTML, Markdown) | Cloudflare R2 — global | EU SCCs | | KV cache (short-lived view tokens, signed URLs) | Cloudflare KV — global | EU SCCs | | Product analytics and session replay | 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.** Customer data lives exclusively in managed services: Cloudflare R2 (artifacts), Neon Postgres (primary database), and Cloudflare KV (cache and short-lived tokens). Each vendor applies encryption at rest by default, as documented in their respective security pages. 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: 1. Notify affected customers without undue delay, and in any event within **72 hours** where notification is required under GDPR Art. 33. 2. Provide a description of the incident, the data categories affected, the likely consequences, and the measures taken or proposed. 3. Publish a post-incident summary after remediation. Report a suspected incident to [privacy@display.dev](mailto:privacy@display.dev). --- ## Vulnerability reporting We welcome vulnerability reports. Send them to [report@display.dev](mailto: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](/terms) §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](/cookie-policy) §6. --- ## 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](mailto:privacy@display.dev). --- ## Contact - **Vulnerability reports:** [report@display.dev](mailto:report@display.dev) - **Security incidents:** [privacy@display.dev](mailto:privacy@display.dev) - **Privacy inquiries:** [privacy@display.dev](mailto:privacy@display.dev) **Displaydev OÜ** Ankru 8-23, Tallinn, 11713, Estonia