Overview
This page describes Dock's current security posture at a high level. It supplements, but does not replace, the Terms of Service and Privacy Policy. It is not a warranty, service-level agreement, or claim that a system cannot be compromised. Dock intentionally does not publish secrets, exact detection thresholds, internal correlation logic, infrastructure credentials, or controls whose disclosure would materially weaken security.
Security Principles
- Use multiple controls rather than relying on one security boundary.
- Keep sensitive access and customer-visible data limited to what the feature needs.
- Separate first-party security processing from customer-facing detection.
- Fail closed when a security-sensitive dependency cannot safely complete its job.
- Review and improve controls as Dock's architecture and risks change.
Infrastructure and Transport
Dock uses separate application, database, cache, queue, websocket, webhook, proxy, storage, and third-party platform components. Current services contain checks and configuration support for authenticated database connections, encrypted transport, bounded caches, service authentication, rate limiting, and health monitoring where applicable.
The exact protections of a backing provider can depend on the deployed environment and provider configuration. Dock therefore does not claim that every backing store uses the same encryption, network, or recovery mechanism merely because application-level protections exist for selected data.
Application Security
Dock uses server-side authentication and authorization checks on sensitive routes. Administrative actions are permission-gated, and browser-facing administrative mutations use origin/CSRF controls. Other controls used across the current services include request and quota limits, signed internal requests, webhook destination validation, idempotency controls, websocket token validation, and bounded retry behavior.
Supported server-profile avatar and banner uploads are bounded by file size and type, checked against their actual file signatures and structure, decoded and normalized, and passed through the configured automated moderation pipeline before an allowed image is activated. If the required moderation path is unavailable, the current image flow fails closed rather than applying an unchecked new image. This does not mean every text field or every item of content across Dock is proactively reviewed before use.
Data Protection
Current API code applies authenticated AES-256-GCM encryption to selected sensitive values, including protected IP values, billing email fields, and stored webhook secrets. HMACs or hashes are used for selected lookup and verification purposes where the original value is not required. Versioned encryption-key handling supports key rotation for protected fields.
These are field-level application protections, not a claim that every field, log, cache, object, backup, or provider-managed store uses application-level encryption. Infrastructure-level protection is separately determined by the deployed service and provider.
Payment-card entry is handled through Stripe-supported payment flows. Dock does not intentionally store full payment-card numbers or CVC values in its own production database.
Access Control
Dock's current browser-facing administration routes are restricted to the service operator and still require the relevant administrative permission checks. Sensitive administrative workflows can record audit information, and account/guild controls also enforce the permissions required for the feature being used.
This page does not claim that source code alone proves who could access provider consoles, infrastructure, or backups. Those operational permissions must remain restricted and reviewed separately from application authorization.
API Keys, Sessions, and Service Credentials
Dock uses protected representations for current credential and secret-handling paths, including HMAC-based API-key lookup support, encrypted webhook signing secrets, signed internal service requests, session protections, and scoped websocket tokens. Credentials may be rotated, revoked, disabled, or re-authenticated when compromise or abuse is reasonably suspected.
Do not commit API keys, session tokens, webhook secrets, or other credentials to public source control or expose server-side secrets in client-side code.
Abuse Prevention and Detection Safety
Dock uses rate limits, verification checks, permission checks, account restrictions, security signals, and review workflows to protect the Services and participating communities. A VPN, proxy, shared network, young account, device similarity, or possible association is context rather than automatic proof of misconduct.
Customer-facing Alt Detection uses an explicit customer-disclosure context and applies source, guild, privacy-state, expiry, and recipient controls before permitted evidence is used. Current customer assessments can use authorized account links, same-community verification context, and bounded review signals. Relationship-inference evidence that requires additional approval is not automatically admitted into ordinary customer results.
Serious moderation actions based on inference-only or other non-direct evidence are subject to server-side review controls. Customer-facing results are review signals rather than proof, and ordinary results are not intended to expose raw IP histories, device secrets, billing data, or Dock's private correlation logic.
Logging and Monitoring
Dock records operational information needed to run and protect the Services, such as health, API, authentication, billing, moderation, profile-change, error, rate-limit, webhook, and security events.
Several current services apply structured redaction to sensitive log fields, and database mutation logging is designed to record operation and field names rather than document values. Dock still treats logging as a data-handling surface: diagnostic records may contain bounded identifiers needed to investigate an event, so logs should not be treated as automatically anonymous or secret-free merely because redaction exists.
Incident Response and Privacy Requests
Dock may investigate suspected incidents, restrict affected access, preserve necessary evidence, rotate credentials, apply fixes, recover services, and provide notifications where applicable law or a binding platform obligation requires them.
Dock also has an authenticated privacy-request workflow with recent authentication, billing-cancellation checks for account deletion requests, account processing fences, per-category review tasks, retention decisions, and an administrative review surface. Guild-owned API keys remain associated with their guild. An active request can restrict customer-facing processing while it is reviewed.
The request workflow is not a promise of instantaneous physical deletion from every external store, queue, delivered webhook, or backup. Some categories require reviewed store-specific procedures, and already-delivered information cannot always be recalled. See the Privacy Policy for Dock's retention and request rules.
Backups and Recovery
Dock may use backups, snapshots, or provider recovery features where configured. Backup scope, retention, and provider protection vary by system.
Dock's privacy-recovery design includes a restore barrier so restored account data can be quarantined while current privacy restrictions are reconciled. This is intended to reduce the risk that a stale restore silently reactivates information that should remain restricted. Deleted information may nevertheless remain in a protected backup until the applicable rotation or reviewed recovery process removes it.
Responsible Disclosure
Send vulnerability reports to [email protected]. Include enough information to reproduce and assess the issue without unnecessarily copying personal data.
- Test only systems and accounts you own or are expressly authorized to test.
- Stop after obtaining enough information to demonstrate the issue.
- Do not perform denial-of-service, destructive testing, persistence, phishing, social engineering, or data exfiltration.
- Do not use a vulnerability to demand payment, threaten disclosure, or engage in extortion.
Dock welcomes good-faith research that stays within these boundaries and is promptly reported. Dock does not intend to pursue a civil claim solely because of good-faith research that follows this published policy. This does not grant legal immunity or bind providers, regulators, law enforcement, courts, or other third parties.
Third-Party Services
Dock depends on providers including Discord, Roblox, Stripe, Cloudflare, hosting, storage, database, monitoring, and networking services. Those providers operate systems outside Dock's direct technical control and apply their own security, privacy, availability, and platform requirements.
Contact
Security reports: [email protected]
Privacy questions: [email protected]
Legal notices: [email protected]
Support: Dock support server