Abuse Controls & Rate Limiting
Relevant source files
The following files were used as context for generating this wiki page:
Introduction
Abuse controls and rate limiting within the LiveCanvas backend are designed to protect the system from malicious activity, account enumeration, and resource exhaustion. These mechanisms are integrated into both the application and endpoint layers, ensuring that sensitive operations—such as authentication, live session participation, and social interactions—remain secure and available.
The system prioritizes secure credential handling, relationship-based access control, and auditable event logging to maintain environment integrity. By enforcing strict boundaries between public and private content, the architecture prevents unauthorized data access (IDOR/CWE-639) while maintaining performance through tiered rate limiting.
Rate Limiting Architecture
The backend implements rate limiting at multiple levels to ensure high availability and prevent brute-force attacks on sensitive endpoints.
Application and Endpoint Layers
Rate limiting is applied both globally at the application level and specifically at individual endpoints. This tiered approach is particularly critical for sensitive authentication events, such as login attempts and password resets.
- Global Application Layer: General protection against traffic spikes.
- Endpoint Layer: Specific limits for high-risk mutations like
signUp,logIn, andbeginAuthChallenge.
Sources: ARCHITECTURE.md:417-418, mobile/schema.graphql:86-100
Verification Flow Idempotency
Verification flows are designed to be idempotent and resistant to account enumeration. This ensures that repeated requests to verify email or phone records do not leak information about whether an account exists and do not consume excessive backend resources.
Sources: ARCHITECTURE.md:420-422, mobile/schema.graphql:169-178
Authentication & Credential Security
The system employs several mechanisms to prevent credential abuse and unauthorized account access.
Secure Token Management
LiveCanvas uses a robust token model to manage sessions and verification.
- Hashing: All persisted tokens, including session and refresh tokens, are stored using SHA3-based hashing rather than SHA-2.
- One-Time Exposure: Raw token secrets are returned to the client exactly once and are never stored in a recoverable form in the database.
- UUIDv7 Identifiers: The
user_tokenstable uses Postgres-generated UUIDv7 identifiers to prevent ID predictability.
Sources: AGENTS.md:7-9, ARCHITECTURE.md:283-300
Security Logic Flow
The following diagram illustrates the sequence for authenticating a request and applying abuse controls.
Social & Relationship Access Controls
Abuse is mitigated in social contexts by enforcing strict visibility rules and allowing users to restrict access via blocking and muting.
Relationship-Based Visibility
The Social context enforces access rules based on the relationship between users. This layer ensures that private accounts can only be viewed by approved followers and that blocked users cannot interact with the blocker.
- Blocks: Hard access restrictions that override any other visibility rules.
- Mutes: Allows users to suppress content from specific creators without necessarily severing the follow relationship.
- IDOR Prevention: GraphQL node fetchers and child field resolvers re-apply viewer authorization to prevent IDOR (
CWE-639) via globally refetchable IDs.
Sources: ARCHITECTURE.md:162-167, ARCHITECTURE.md:389-397, AGENTS.md:12-14
Social Control Features
| Feature | Description | Relevant GraphQL Mutation |
|---|---|---|
| Block | Hard restriction; overrides visibility | blockUser(input: BlockUserInput!) |
| Mute | Suppresses content/notifications | muteUser(input: MuteUserInput!) |
| Privacy Mode | Toggles between Public and Private account state | updateViewerPrivacyMode(...) |
| Follow Request | Requires manual approval for private accounts | acceptFollowRequest(...) |
Sources: mobile/schema.graphql:102-132, ARCHITECTURE.md:164-167
Realtime & Session Moderation
Live sessions and chat require specialized abuse controls due to their transient and high-throughput nature.
Channel Authorization
All Phoenix Channel joins are authenticated and authorized per topic. The system validates:
- Viewer Eligibility: Based on social relationships (e.g., if the user is blocked).
- Participation Role: Host vs. Viewer capabilities.
- Session Access: Whether the live session is still active or public.
Sources: ARCHITECTURE.md:401-408
Chat Moderation
The Chat context is decoupled from the Live context to handle moderation and retention separately. It supports the removal of messages by moderators or the system.
- System Events: Messages can be flagged with a
statusofREMOVED. - Auditability: Moderation history is retained in the
chat_messagestable for auditability.
Sources: mobile/schema.graphql:439-444, ARCHITECTURE.md:184-188
Auditing & Observability
To detect and respond to abuse, the system maintains auditable records and instruments critical flows with Telemetry.
Sensitive Event Logging
The backend keeps records for the following sensitive authentication events:
- Login success and failure attempts.
- Credential linking or unlinking (e.g., adding a phone number or OAuth provider).
- Token revocation events.
Sources: ARCHITECTURE.md:418-420
Telemetry Instrumentation
Key flows are monitored to identify patterns indicative of abuse, such as high failure rates or abnormal message throughput.
- Auth Failures: High frequency suggests brute-force or enumeration.
- Message Throughput: Used to detect chat spam.
- Channel Join Failures: May indicate unauthorized scraping attempts.
Sources: ARCHITECTURE.md:448-456
Summary
LiveCanvas implements a multi-layered defense strategy against abuse. By combining cryptographic token security (SHA3, UUIDv7) with granular relationship-based authorization and application-level rate limiting, the system ensures that user data and platform resources are protected. Realtime moderation and extensive telemetry provide the necessary visibility for ongoing operational security and incident response.