Social network security checklist

• All reads and writes go through RLS and a single `canView(viewer, post)` function that applies visibility (public|followers|private), private-account approval, blocks, mutes and suspended-author rules; a hidden or removed post is never returned by any list, search, notification or cache.
• DM reads and writes require membership checked in RLS; blocked users cannot create or continue threads; message-request folder and daily first-contact cap stop cold-DM spam.

• Profiles, follows, DMs, location and device data are personal data: DMs are never logged or indexed for search, EXIF/GPS is stripped from every image, export and erase endpoints exist, and logs hold hashed user ids only.

• Validate declared size and MIME, verify magic bytes, enforce max pixels and bytes, re-encode every image in a resource-limited sandbox (CPU, memory, wall clock, no network) so polyglot or decompression-bomb files cannot survive; serve user media from a separate cookieless origin with Content-Disposition and X-Content-Type-Options: nosniff.

• Post bodies are stored as plain text with entity spans; mentions, links and hashtags are rendered by React as elements, never raw HTML; link previews are fetched server-side with an SSRF guard (public IPs only, size/time caps) and cached.
• Uploaded media is untrusted: virus-scan sources, hash-match against a known-bad list where a provider exists, route flagged items to a restricted review queue, and keep a legal reporting path for illegal content (including CSAM reporting duty).

• One report per reporter per target; reports from accounts with poor accuracy are down-weighted so coordinated reporting cannot auto-remove content; every moderator action is audit-logged and appealable.
• Every billable resource has a code-enforced cap that fails closed: media storage per user/plan, upload bytes per day, image jobs per user per day, fan-out rows per post, email/push per user per day, SSE connections per user, and total egress per plan; at the cap the operation is refused, never queued or silently degraded.

• Minimum age gate at signup, region-aware consent for personalisation and feed events, and a documented takedown and appeal process for illegal-content and DMCA notices.

• Signing secrets for cursors, upload callbacks and unsubscribe links are env-only, rotated without downtime, and never logged or sent to the client.

• GDPR / CCPA (applies to EU or California users): Profiles, follow graph, DMs and feed events are personal data: lawful basis and consent for personalisation, export and erase endpoints, DM and event retention limits, erasure propagates to timeline entries, media objects, search rows and caches.
• Illegal content and CSAM reporting (applies to user-uploaded media): Operators of user-generated content platforms need a notice-and-action process, a designated contact and, where required, mandatory reporting of CSAM to the competent authority.
• Digital Services Act / Online Safety rules (applies to EU or UK audience): Transparent moderation policy, statements of reasons for removals, an appeal channel and risk assessments scale with audience size.
• COPPA / minimum age (applies to minors may sign up): Under-13 (or local digital-consent-age) users need verified parental consent or must be blocked; an age gate at signup and an under-age report path are required.
• DMCA (applies to user-uploaded media): Notice-and-takedown flow with counter-notice and a repeat-infringer policy for uploaded media.
• Accessibility: Alt text on images, keyboard-operable composer and feed, reduced-motion support, WCAG 2.2 AA contrast.

• media storage gb: per-plan and per-user quota (MEDIA_STORAGE_MB_PER_USER); presign refused at 100%.
• upload bytes per user day: hard daily cap; presign refused over the cap.
• image processing minutes month: per-plan cap enforced before a process_media job is queued; metered into usage_events.
• fanout rows per post: FANOUT_MAX_ROWS_PER_POST; beyond it the author switches to pull mode instead of writing more.
• cdn egress gb month: per-plan cap; image requests beyond it are served as low-resolution variants only, then refused.
• notification emails per user day: NOTIFY_EMAILS_PER_USER_DAY and a global monthly send cap; sends refused at the cap.

Forge64 gives every app its own Postgres database and runs a quality gate that flags unauthenticated writes and secrets in client code before you see the app. It does not replace your own testing, and it holds no third-party security certification today.

This is a reference design for the category, not a promise that every item is generated today. Built-ins such as email, background jobs, file uploads and search are coming soon, so anything here that needs them is something you add yourself for now.

• Sign in as two different users and try to open each other's records by changing the id in the address.
• Submit each form with an empty value, a very long value and a script tag, and check the result.
• Call each write endpoint without signing in and check that it refuses.

What is the biggest security risk in a social network?

All reads and writes go through RLS and a single `canView(viewer, post)` function that applies visibility (public|followers|private), private-account approval, blocks, mutes and suspended-author rules; a hidden or removed post is never returned by any list, search, notification or cache.

Does a social network have compliance obligations?

GDPR / CCPA, if you have EU or California users: Profiles, follow graph, DMs and feed events are personal data: lawful basis and consent for personalisation, export and erase endpoints, DM and event retention limits, erasure propagates to timeline entries, media objects, search rows and caches. This is a starting point, not legal advice.

Will Forge64 certify my app as secure?

No. Forge64 holds no third-party security certification today and does not certify apps. The checklist is a way to test your own app.

• How to build a social network
• Social network architecture
• Example prompt for a social network
• Social network scaling checklist
• Often combined: marketplace
• Often combined: content site
• All app types