1. Current controls
Workspace isolation
Authenticated requests carry an active workspace, and server-side access checks scope customer data to that workspace. Member roles distinguish owner, admin, sales, and support access.
Authentication
Passwords are one-way hashed. Access tokens are short-lived and kept in application memory; refresh tokens use an HTTP-only cookie that is Secure in production, SameSite=Lax, scoped to authentication routes, and rotated.
Network and application controls
Production traffic uses HTTPS. Known frontend origins are allowlisted, sensitive routes are rate-limited, validation is applied at API boundaries, and security headers are set by the service edge.
Provider events
Meta webhook configuration uses a verification token for subscription checks and HMAC signature validation over the raw request body for incoming event authenticity.
Operations and monitoring
Error reporting, public availability monitoring, release identification, application health checks, restricted infrastructure access, and operational runbooks support detection and recovery.
Backups and recovery
Database backups and isolated restore procedures support recovery. Backup snapshots can contain data later deleted from active systems; restore procedures must reapply verified deletion handling before or while restored data returns to active use.
2. Honest boundaries
No security programme eliminates risk. Wazzl does not claim a security certification, formal penetration-test report, public bug-bounty programme, or contractual recovery objective on this page. Provider availability, customer device security, Meta account controls, and customer-configured access also affect the overall security of a workspace.
Questions about a specific control, evidence request, or customer risk assessment can be sent to the security contact. Availability of additional evidence depends on sensitivity and a suitable confidentiality arrangement.
3. Customer responsibilities
- Use unique, strong passwords and protect the email accounts used for Wazzl and Meta administration.
- Give each teammate an individual account and the least privilege needed for their role.
- Remove departed members promptly and review owner/admin access regularly.
- Restrict access to Meta business assets, system users, app secrets, and tokens; rotate a credential after suspected exposure.
- Do not place passwords, access tokens, payment-card data, government identifiers, or unnecessary sensitive content in contacts, notes, chat, or support requests.
- Report unexpected messages, session activity, workspace access, or channel behaviour promptly.
4. Report a suspected vulnerability
Email [email protected] with “Wazzl security report” in the subject. Include the affected URL or function, a clear description, safe reproduction steps, and a reply address. Do not include credentials or customer data.
Do not access another person’s data, modify or delete records, send messages, disrupt availability, use automated high-volume testing, or publicly disclose an unresolved issue. Stop testing once enough information exists to describe the concern. Wazzl will review good-faith reports, but this page does not promise a response time, reward, safe-harbour term, or particular result.
5. Security incidents
Wazzl investigates suspected incidents, works to contain and recover service, and preserves relevant evidence. If an incident materially affects customer data, notices and processor assistance will be provided as required by applicable law and an applicable written agreement. Public service information may also appear on the status page.
6. Related information
Read the privacy policy, provider list, and data-processing terms summary for the related data roles and operational boundaries.