Privacy & Security

This page describes how static.bio handles privacy and security for public profile pages and the dashboard.

The public surface is intentionally constrained:

  • static HTML + CSS
  • no JS execution
  • no third-party scripts/resources

This eliminates large classes of tracking and client-side security risk by design.

Data collected and stored

Profile data

Stored per profile:

  • username, displayName, bio
  • avatar URL (or hosted avatar reference, depending on implementation)
  • theme selection (themeId) and sparse theme options (themeOptions)
  • plan (FREE | LIFETIME)
  • link list (label, URL, order, enabled)

Operational metadata

Typical operational data may include:

  • timestamps (createdAt/updatedAt)
  • domain mappings (for custom domains)
  • basic server logs (for reliability and abuse prevention)

Public profiles (privacy)

No third-party scripts

Public profile pages do not load third-party JavaScript and do not embed third-party trackers.

No cookies required for public viewing

Public profile pages do not require cookies to render. If you set any cookies at all, they should be limited to:

  • security controls at the edge (rare)
  • abuse prevention

Avoid setting analytics or personalization cookies on the public surface.

No client fingerprinting

Because there is no client runtime, static.bio does not run browser fingerprinting code on public pages.

Analytics (click tracking)

Analytics is implemented as a server-side redirect, not as client-side tracking.

Default: analytics off

By default, profile links point directly to the destination URLs.

Optional: analytics on

When enabled, link hrefs point to a same-origin redirect endpoint (e.g., /r/<linkId>):

  1. A request hits the redirect endpoint
  2. The server records a click event
  3. The server responds with an HTTP redirect to the final URL

This allows basic click counts without:

  • scripts on the profile page
  • third-party analytics

What can be logged (keep it minimal)

If analytics is enabled, a click event may include:

  • link id
  • timestamp
  • coarse request metadata (e.g., user-agent or IP) only if necessary for abuse prevention or deduplication

If you store IPs, either:

  • hash/truncate them, or
  • store them short-lived with a clear retention policy

Document this policy explicitly when analytics is exposed as a user-facing feature.

Public profiles (security)

HTML escaping (XSS prevention)

All user-supplied content is HTML-escaped before being rendered. The system does not allow raw HTML injection in bios or link labels.

URL handling (link safety)

Links are user-controlled. Minimum recommended protections:

  • allow only http: and https: URLs
  • reject javascript:, data:, and other dangerous schemes
  • normalize and validate URLs at save time

Security headers

Serve public pages with a conservative baseline:

  • Content-Security-Policy (CSP) that disallows scripts by default
  • X-Content-Type-Options: nosniff
  • Referrer-Policy (consider strict-origin-when-cross-origin)
  • Permissions-Policy (deny unnecessary APIs)

A tight CSP is feasible because public pages do not require JS.

Embeds and iframes

Public profiles should not embed third-party iframes or widgets. If a future feature requires them, it must be explicitly scoped and documented as a contract change.

Dashboard (privacy & security)

The dashboard is authenticated and may use JavaScript. It is not part of the "No-JS public profile" contract.

Minimum expectations:

  • secure session management (HTTP-only cookies, CSRF protection if applicable)
  • least-privilege access control
  • rate limiting on auth and sensitive endpoints
  • audit logs for critical changes (optional but recommended)

Data retention (recommended stance)

Set clear retention policies, especially for analytics:

  • keep only what you need
  • keep it for as short a period as possible
  • document retention windows once analytics ships

Known tradeoffs

  • No-JS prevents rich client-side privacy UX. Cookie banners and consent flows are not relevant on public pages because there are no third-party scripts, but the dashboard may still require standard compliance depending on your jurisdiction.
  • Server logs still exist. "No tracking" does not mean "no logs." Reliability and abuse prevention require basic operational logging.
  • External avatars may leak requests. If avatar URLs point to third-party hosts, the browser will request them. If you want strict same-origin guarantees, proxy/host avatars.
  • Analytics via redirects is limited. You can count clicks, but you won't measure client-side engagement (by design).

Contract tests (privacy & security)

These invariants should be regression-tested:

  • Public HTML contains 0 <script> tags.
  • Public pages load no third-party scripts/resources (all resources are same-origin, except possibly user-provided avatars if allowed).
  • All user-provided text is HTML-escaped.
  • Saved links reject dangerous URL schemes (javascript:, data:).
  • CSP isn't permissive (no unsafe-inline scripts; ideally script-src 'none' or equivalent).

How to verify

See: Verify (curl cookbook) for copy/paste checks of:

  • presence of scripts
  • third-party resource hosts
  • response headers (CSP, referrer policy, etc.)