Security
Pagepost turns HTML and Markdown files into shareable links. People forward those links into Slack channels, Notion pages, and email threads — often with executives, clients, or sensitive context in the room. This page describes, concretely, what we do to protect that content and the people who view it. It is not a marketing page; if something is not listed here, assume we have not built it yet.
Encryption at rest
File contents are encrypted with AES-256-GCM before they ever reach our storage backend (Vercel Blob). The encryption key lives in our server environment and is never sent to the client. Decryption only happens at request time, on the server, when an authorised viewer fetches the file.
Slack bot tokens — the credentials our Slack app holds for workspaces that have installed it — are encrypted at rest with the same algorithm and the same key.
All traffic to and from Pagepost is served over HTTPS.
How we contain uploaded HTML
Pagepost intentionally serves uploaded HTML without stripping scripts — interactive dashboards are the value the product delivers. Instead of sanitising the content, we contain it. Uploaded files are served from a separate origin — raw.pagepost.app — and embedded into the viewer page (pagepost.app/x/<id>) via a sandboxed <iframe>. That two-part split is what protects you:
- Browser origin isolation. Because the uploaded file lives on
raw.pagepost.app, it is a different origin frompagepost.appas far as the browser is concerned. Uploaded JavaScript cannot read your Pagepost session cookie, cannot call our APIs as you, and cannot touch any other link or account data. - Iframe sandbox. The embedding
<iframe>is sandboxed to block top-level navigation (so uploaded HTML cannot redirect you to a phishing page) and same-origin escapes. Uploaded HTML is allowed to open new tabs, but aCross-Origin-Opener-Policyon the viewer page severs the popup's link back to its opener as soon as it navigates cross-origin — so the popup cannot reach back and redirect the pagepost.app page either. - Content-Security-Policy on the raw origin. We enforce
connect-src 'none'andform-action 'none', so uploaded scripts cannot phone home viafetch,XMLHttpRequest,WebSocket,navigator.sendBeacon, or form submissions to attacker-controlled URLs. - Sensitive device APIs blocked. A Permissions-Policy header on
raw.pagepost.appdenies access to the camera, microphone, geolocation, payment, USB, serial, Bluetooth, and MIDI APIs from inside uploaded HTML — even if the file tries to ask for them. - No direct-link spoofing. If someone is tricked into clicking a
raw.pagepost.app/raw/<id>URL at the top level, the server redirects them topagepost.app/x/<id>. You always see uploaded HTML inside the Pagepost viewer chrome — never alone in the address bar at the raw subdomain — so a malicious file cannot pose as a Pagepost login or admin page.
Uploaded HTML is allowed to trigger file downloads, open new tabs, use the clipboard, and print — capabilities that interactive tools (canvases, calculators, dashboards that export to Word or PDF) legitimately need. Those actions affect the visitor's own browser; they cannot reach Pagepost or the network.
The viewer page itself (pagepost.app/x/<id>) cannot be embedded in third-party sites. That means owner controls — rename, revoke, change expiry, delete — cannot be clickjacked by an attacker who hides the page behind a misleading overlay on their own site.
Markdown is sanitised; HTML is not
Markdown uploads are rendered through a strict allowlist of HTML tags and attributes — scripts and inline event handlers are stripped before the file is shown. That matches what most Markdown users expect: text and formatting, not arbitrary code.
HTML uploads are served as-is. This is a deliberate design choice — the product is built for sharing rich, scripted documents — and the sandbox above is what protects users instead of content scrubbing.
What we record about viewers
When someone opens one of your links, we record the timestamp, a hashed IP address, the browser user-agent string, and the Slack user ID if the viewer is signed in. Raw IP addresses are never written to disk: every IP is HMAC-hashed with a server-side secret before storage, which means we can detect repeat views without retaining the underlying IP.
Viewer telemetry is cascade-deleted when the link is deleted or the owner deletes their account. See the Privacy Policy for the full data inventory and your rights under GDPR.
Authentication and session
Sign-in goes through Slack OAuth and (for accounts that have linked one) Google OAuth. We do not store passwords. The session cookie is an HMAC-signed value, marked HttpOnly, Secure, and SameSite, which prevents JavaScript on any page — including uploaded HTML — from reading it and prevents cross-site request forgery on state-changing endpoints.
Link controls owners can use
- Revoke a link instantly. Future opens return a revoked-link page.
- Expire a link on a chosen date.
- Restrict to your workspace. Slack-uploaded links default to workspace-only access; viewers outside the workspace are challenged to sign in. The check is enforced on both origins: the viewer page verifies your session, then authorises the content frame with a short-lived signed token scoped to that one link — your session cookie itself never crosses to
raw.pagepost.app. - Delete the file, its metadata, and all viewer telemetry tied to it.
- Audit log. Every owner action on a link (rename, permission change, expiry change, revoke, delete) is recorded with a timestamp, so you can see the history of a link.
From your account page you can also export all of your data as JSON or delete your account entirely; deletion cascades to files, links, telemetry, and audit log.
Discoverability
Link pages are served with X-Robots-Tag: noindex, nofollow so they do not appear in search engines. Referrer-Policy: no-referrer ensures the link itself is not leaked to third parties when a viewer clicks a link inside the document.
What we don't have (yet)
Pagepost is currently operated as a small, single-operator project. We want to be clear about the boundaries of our current security posture:
- No SOC 2, ISO 27001, or HIPAA certification. If your organisation requires one of these for vendor approval, Pagepost is not the right fit today.
- No formal SLA or uptime guarantee. The service is provided as-is during the current testing phase.
- No customer-managed encryption keys. Encryption keys are held by Pagepost.
- No region selection for data residency. Hosting and storage are operated by Vercel and Turso; data may transit and rest in the United States. See §4 of the Privacy Policy for the legal basis.
- No bug bounty program. Responsible disclosure is handled informally over email (see below).
If any of these would block you from using Pagepost for sensitive work, please tell us — knowing what is missing helps us prioritise. For organisations with stricter data-residency, compliance, or air-gapped-network requirements, we can also discuss an in-house installation of Pagepost running on your own infrastructure; contact us at hello@pagepost.app to scope it.
Reporting a vulnerability
If you believe you have found a security issue in Pagepost, email security@pagepost.app with a description of the issue and steps to reproduce. Please do not publicly disclose the issue until we have had a reasonable opportunity to respond. We aim to acknowledge reports within a few business days.
Support
For questions, bug reports, and feature requests, email hello@pagepost.app. We aim to respond to support requests within two business days (Monday–Friday, Athens time). Security reports sent to security@pagepost.app are triaged separately and prioritised over general support.