sillyspace/docs/threat-model.md

Threat Model

Bliish.space intentionally allows user-controlled profiles. That makes security boundaries explicit and non-optional.

Assets

• Account credentials.
• Session tokens.
• CSRF tokens.
• Email addresses.
• Profile data.
• Uploaded profile images, post images, and audio.
• Private profile visibility.
• Admin actions, reports, and automod rules.
• SQLite database and uploads directory.

Actors

• Anonymous visitor.
• Signed-up user.
• Profile owner.
• Friend.
• Moderator.
• Admin.
• Instance operator.
• Malicious user.
• Compromised reverse proxy or host.

Trust Boundaries

• Browser to Hono request.
• Cookie/session middleware to route handlers.
• Form parser to validators.
• Sanitizer to HTML renderer.
• Upload parser to filesystem.
• Route handler to SQLite query module.
• Admin-only routes.
• Reverse proxy to app process.

Primary Risks

Cross-Site Scripting

Risk: profile bio, skin HTML, posts, comments, blogs, private messages, and reports render user content.

Controls:

• sanitize before storage;
• restrict tags, attributes, schemes, and inline styles;
• allow skin CSS only through the skin sanitizer, which strips active code, unsafe URL schemes, arbitrary CSS attribute selectors, high-risk selector functions, and absolute/fixed/sticky positioning, while keeping page-level skin selectors variable-only and preserving documented profile skin hooks;
• allow skin resource URLs only when they are local paths or HTTPS URLs;
• allow iframe embeds only for host/path-validated mainstream player URLs, with fixed sandbox and referrer policy attributes;
• avoid rendering raw input;
• keep sanitizer tests near sanitizer code;
• render stored sanitized HTML through the shared trustedHtml boundary, and treat any direct dangerouslySetInnerHTML use as security-sensitive.

CSRF

Risk: form-first app has many mutating POST routes.

Controls:

• form-based mutations require CSRF tokens;
• mutating form actions use per-action rate limits backed by short-lived SQLite counters keyed to accounts or submitted form subjects;
• invalid tokens return 403;
• cookies use SameSite=Lax;
• destructive forms stay POST-only.

Email verification is the exception: /verify/:token consumes a one-time token stored as a hash in SQLite because the token itself authorizes that action.

Session Theft

Risk: stolen session token gives account access.

Controls:

• random opaque tokens;
• store only token hashes;
• HTTP-only cookie;
• secure cookies when base URL is HTTPS;
• revocation on logout.

Upload Abuse

Risk: executable files, oversized files, or disguised content.

Controls:

• size cap;
• request body size cap before form parsing;
• allowed MIME and extension;
• file signature validation;
• local image normalization before storage;
• random filenames;
• separate upload buckets for profile images, post images, and theme songs;
• uploads stored under the configured upload directory;
• production deployment docs place uploads under /var/lib/bliishspace/uploads;
• local development defaults use data/uploads, which is ignored by git.

Authorization Bypass

Risk: user mutates or reads resources they should not access.

Controls:

• route-level auth checks;
• owner/admin checks before edit/delete;
• moderator checks for report queue actions, with role hierarchy checks before staff can delete content or ban an author;
• admin-only automod rule management, with rule length limits, regex compile validation, scan length caps, default critical rule packs, evasion-aware text normalization, and review matches routed through the same moderated report queue;
• private profile checks on direct profile, profile friends, profile blog, and wall routes;
• group post creation, props, and comments require group membership;
• protected admin friendship and default group membership checks prevent users from disconnecting from the instance admin account or leaving group id 1;
• per-entry blog privacy checks for public, friends-only, and private diary entries;
• admin routes require the admin role; report moderation routes require a staff role with moderation capability.

Open Redirect

Risk: attacker abuses redirect after delete actions.

Controls:

• redirects from request headers are restricted to local paths or same-origin URLs.

Third-Party Profile Resources

Risk: customized skins can cause visitor browsers to fetch HTTPS images, CSS backgrounds, Google Fonts resources, or whitelisted embedded players chosen by profile authors.

Controls:

• remote resources are limited to HTTPS URLs by the skin sanitizer;
• iframe embeds are limited to mainstream player URLs such as YouTube, SoundCloud, Vimeo, Spotify, Bandcamp, TikTok, and Dailymotion, rewritten or validated by the skin sanitizer, sandboxed, and constrained by CSP frame-src;
• ordinary user text fields do not allow image tags;
• instance operators can tighten sanitizeSkinHtml and CSP if they want local-only skin assets.

Data Loss

Risk: SQLite file or uploads are lost or corrupted.

Controls:

• WAL mode;
• documented backup and restore;
• uploads and database kept in predictable directories.

Residual Risks

• Sanitizer policy may need tightening as skin support expands.
• Instance operators can weaken privacy with proxy logs or CDN configuration.
• New features may miss moderation edge cases.
• Deleted data can remain in backups outside the app.