Authentication
Protected areas should require an authenticated session, while public pages expose only intentionally public content.
Security is not a single feature. The platform should combine authentication, authorization, database policies, careful UI exposure, session handling, and operational monitoring.
Protected areas should require an authenticated session, while public pages expose only intentionally public content.
Sensitive tables should use server-side authorization and row-level security so a user cannot simply request another user's protected records.
Private conversation reads and writes should be restricted to the users who belong to that conversation.
The UI should avoid displaying private credentials, contact details, tokens, or internal identifiers as community profile information.
Authentication sessions should be handled through the platform's supported secure session mechanisms rather than exposing tokens in page content.
If you find a security problem, do not exploit other users or publish private information. Preserve only the minimum evidence needed to describe the issue to the site operator.
Security claims should match the actual production configuration. No service can promise that an account, message, or website is impossible to compromise. Never enter passwords, payment secrets, recovery codes, or other sensitive credentials into public rooms, posts, or messages.
Authorization must be enforced at the data layer. Client-side hiding is not a security boundary. Production deployments should also use HTTPS, secure environment variables, dependency updates, logging/monitoring, rate limiting where appropriate, backups, and a documented incident-response process.