ZyraLink
We take user safety seriously. This page explains the protections currently implemented, the controls available to you, and where the public security story still needs further verification.
Passwords are stored as one-way password hashes; ZyraLink does not store your plaintext password.
Session cookies are cryptographically signed. Tampering with a cookie immediately invalidates the session.
Login, registration, and many API actions are rate-limited to slow brute-force attempts and abusive bursts.
Administrators can ban specific IPs from accessing the platform entirely for serious violations.
Push notifications use VAPID key pairs, ensuring only ZyraLink's server can send you notifications.
Administrative tools support account bans, locks, message actions, reports, and other moderation workflows.
Protected HTTP requests and new real-time connections re-check account status and session version before allowing access.
Users can create recovery details in Privacy settings and use the recovery flow to lock the account and end active sessions.
A separate unlock code can restore access after a user-initiated lockdown, subject to the recovery flow configured for the account.
ZyraLink is privacy-focused, not an end-to-end encrypted messenger. The service handles messages so it can deliver chat, support moderation, manage recovery, and enforce account controls. The summary below is based on the supplied server implementation and is intended to be specific about both protections and limits.
| Area | Current implementation and boundary |
|---|---|
| Session cookies | Flask’s signed session cookie is HttpOnly. Secure is enabled when HTTPS is detected and is forced for production unless insecure HTTP is explicitly allowed. SameSite defaults to Lax; Strict or None can be configured, and None is rejected unless Secure is active. The permanent session lifetime is seven days and refreshes on use. |
| CSRF protection | State-changing routes use a per-session CSRF token accepted through the X-CSRF-Token header, JSON, or form data. A token is issued at /api/csrf-token. Login, registration, and token-based recovery entry points are intentionally outside the cookie-authenticated CSRF flow; they rely on submitted credentials or recovery tokens instead. |
| WebSocket authentication | Socket.IO is restricted to the normalized same-origin or explicitly allowed origins. The browser session cookie identifies the account. Join and guarded events re-check account status and the database session version, and stale, banned, locked, or invalidated sessions are disconnected. This is session-based authorization, not a separate end-to-end message-authentication protocol. |
| Authorization model | Protected HTTP and socket actions use the authenticated session username, database account state, ownership checks, DM participants, and administrator checks. Admin actions require an account recognized as admin and, for sensitive operations, additional configured secrets. A complete externally reviewed authorization matrix is not currently published. |
| Password requirements | Normal registration requires a password of 8–128 characters, plus a username, email address, and birth year proving an age of at least 13. Passwords are stored through Werkzeug password hashing. No stronger complexity rule such as a required symbol set is enforced by the registration route. |
| Rate limits | Verified examples include five login attempts per minute per IP and per username, three registrations per minute per IP, a global 300-request-per-10-seconds IP burst guard, eight public or DM messages per user per 10 seconds, and 120 guarded socket events per connection per 10 seconds. Emergency lock and unlock routes use five attempts per IP and three per account over 30 minutes; recovery-token and unlock-code management routes use shorter five-minute windows. |
| Brute-force protection | Login checks are limited by IP and username, banned IPs and devices are rejected, and dummy password hashes are used for some nonexistent-account recovery checks to reduce timing differences. These controls reduce abuse; they are not a guarantee that every attack scenario is prevented. |
| Security headers | Responses set CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, HSTS when HTTPS is detected, Cross-Origin-Opener-Policy, Cross-Origin-Resource-Policy, and related hardening headers. The current CSP still permits inline scripts/styles and the Socket.IO CDN because the existing app depends on them. |
| Database and field encryption | The application uses Fernet encryption for message content and selected personal/security fields, with HMAC blind indexes for exact-match lookups. This does not establish whole-database or SQLite-file encryption, and it does not prove that every legacy row or backup is encrypted. |
| Backup encryption | Backup encryption and backup-retention controls are not demonstrated by the supplied application code. No public claim is made that deleted content is “truly gone” from backups. |
| Secret management | Secrets are read from environment variables where configured. The application can fall back to local key files and attempts to set restrictive file permissions, but the supplied code does not demonstrate use of a managed secrets vault, rotation schedule, or independent operational review. |
| Remote account lock | A valid recovery token plus a previously configured unlock code is required. The recovery token is hash-checked, rate-limited, consumed transactionally, and the lock bumps the account’s session version, removes tracked IP sessions, and emits forced logout to active sockets. This protects app-managed sessions; it is not an independently tested guarantee against every persistence, compromise, or infrastructure failure. |
| Deletion semantics | Normal user deletion is generally a soft delete that blanks content, removes reactions, and preserves rows or reply-chain context. Admin hard-delete can remove message rows and related records. Because soft deletion and backups are distinct concerns, ZyraLink does not claim universal or immediate deletion from every storage layer. |
| Tracking and telemetry | The public templates do not include known advertising or analytics tags in the reviewed files. That review does not prove the absence of tracking in every runtime path, infrastructure layer, email provider, push path, or future deployment configuration. |
No measurement or service-level evidence establishes sub-100ms delivery. The marketing copy does not claim it.
The interface is responsive, but “100% mobile-first” is not an independently defined or certified claim.
Normal user deletion is not the same as verified erasure from every database, log, replica, or backup.
No independent penetration test, recurring audit, dependency-scan report, or formal security assessment is included in the public documentation.
Please do not publish exploit details, access another person’s account, or intentionally disrupt the service. Send the affected URL or component, a concise reproduction, impact, and a safe reply address to [email protected]. For implementation bugs without security impact, use [email protected]. The existing Contact page lists the available channels.
Include only the minimum evidence needed to reproduce the issue. Do not include passwords, recovery tokens, private messages, or other user data.
Email the safety teamBefore calling the service production-grade, the public record should eventually include automated security testing, dependency and supply-chain scanning, targeted penetration testing, a documented responsible-disclosure workflow, and recurring independent reviews. The current code and page do not claim that those activities have already happened.
These behaviours will result in account suspension or a permanent ban.
Repeatedly targeting another user with hostile, threatening, or demeaning messages is strictly prohibited.
Content that demeans people based on race, ethnicity, religion, gender, sexual orientation, disability, or nationality will be removed immediately.
Sharing illegal material, content that exploits minors, or unsolicited adult content is a serious violation and may be reported to relevant authorities.
Automated spam, unsolicited bulk messages, and impersonating other users or ZyraLink staff are all violations.
Any attempt to hack, overload, or manipulate the platform's systems — including sending malicious code or exploiting bugs — will result in an immediate permanent ban.
Choose a password you don't use on other services. A mix of letters, numbers, and symbols is best.
Avoid sharing your real name, address, phone number, or financial details in public or private chats.
No ZyraLink admin will ever ask for your password. If someone does, report them immediately.
If you use a shared or public computer, always log out when you are done. ZyraLink sessions last 7 days.
If you experience harassment or see harmful content, contact us with the relevant username, message, or URL. For security vulnerabilities, use the disclosure guidance above and avoid sharing exploit details publicly.
Contact Support