Security
PageWeave's security architecture ensures isolation between platform code and user-generated content.
Domain Isolation
| Domain | Purpose | Trust Level |
|---|---|---|
pageweave.dev |
Dashboard, API, MCP endpoint | Trusted platform code. Strict CSP. |
*.pageweave.site |
Hosted websites | Untrusted user HTML/JS. No platform cookies. |
assets.pageweave.dev |
Platform CSS/JS/fonts | Trusted static assets via CDN. |
Same-origin policy prevents *.pageweave.site JS from accessing pageweave.dev cookies or DOM.
Cookie Policy
- Platform cookies set on
pageweave.devonly __Host-prefix +Secure+SameSite=Strict+Path=/- No platform cookies on
.pageweave.siteparent domain
Content Safety
Abuse Scoring
Every published page is scored for abuse risk:
- Obfuscation techniques (eval, base64, hidden iframes)
- Content length anomalies
- Excessive external links
- Hidden content (display:none, zero-size elements)
- Spam keywords
- Suspicious links (phishing patterns)
Draft Pages
Unpublished pages include <meta name="robots" content="noindex,nofollow"> to prevent premature indexing.
Form Spam Protection
Every form is protected by ALTCHA proof-of-work. Three tiers, settable per form version or site-wide (form setting wins):
- standard — invisible proof-of-work (default)
- code — adds an accessible image/audio code challenge
- strict — harder proof-of-work plus the code challenge
An adaptive shield watches failed submissions per form: under sustained attack it raises protection automatically — site-wide when several forms are hit — and returns to the configured tier once pressure subsides. Owners are notified when protection escalates or is restored. Challenge and verification endpoints are rate-limited.
Spam Scoring and the Spam Folder
Proof-of-work stops volume, not content — so every submission also passes a content check before it is stored. Six quiet signals score it: honeypot, submission speed, duplicate text, links, known scam phrases, and repeated characters. The score routes the submission:
- Inbox — delivered as usual: email notification, webhook, counted.
- Spam folder — kept in the form's spam tab, invisible in the inbox. No email notification, not counted — but the webhook still fires, with a
spamblock describing the verdict. - Discarded — same silent success screen as every submission (senders learn nothing), but no webhook at all. Purged after 30 days; spam-folder rows after 90.
Nothing is deleted silently. You decide per submission: Release moves it back to the inbox and delivers the missed notification (the evidence — score and signals — is kept for your records); Mark as spam files a delivered one away.
One honest edge: an identical resubmission from the same visitor within 10 minutes counts as a repeat signal. A genuine "thanks again" can land in the spam folder — release it and the notification arrives.
Password Protection
Environments and release permalinks can be gated behind a shared password: humans get a localized gate page and an encrypted host-only cookie (30 days, invalidated immediately on password rotation — the cookie binds a sub-second stamp), automation passes the password as a bearer header. Passwords are stored as bcrypt digests only — never in workflow state or tool-call logs. Gated surfaces always serve Cache-Control: private, no-store, including granted requests and hash-marked immutable URLs. The gate POST is rate-limited. See Password Protection for the full mechanics.
Dashboard Protection
X-Frame-Options: DENYon allpageweave.devroutesContent-Security-Policy: frame-ancestors 'none'- Dashboard previews render user HTML in sandboxed iframes
- CORS: API never allows
*.pageweave.siteorigins
Request Handling
- Unknown Host headers → 404
- Page path sanitization: whitelist
[a-z0-9\-_/]only - Metadata escaping in layout templates
- Rate limiting on MCP tools per account
API Key Security
- Keys bypass OAuth scope checks (full access)
- Key rotation from dashboard
- Audit log: all MCP tool calls recorded