Ownership-first security
Keep your support stack inside the boundaries you already trust
The strongest security advantage in ZChat is not a marketing checklist. It is the fact that the software runs on your infrastructure,
uses your deployment standards, and keeps customer conversations inside your chosen environment instead of routing them through a third-party chat vendor.
Data stays in your systems
You decide where transcripts, visitor records, and configuration data live and how they are retained.
Deployment standards are yours
Use your certificates, reverse proxies, network rules, monitoring, and operational controls rather than adapting to a vendor baseline.
AI without forced exposure
Keep AI disabled, connect an external provider, or use private local inference depending on your policy requirements.
How each control actually works
Security claims are easy to make and hard to check, so here is what ZChat does specifically, and how you can verify each one on your own install before trusting it with customer conversations.
Agent credentials
Passwords are stored as PBKDF2-SHA256 with 100,000 iterations and a per-account salt — never reversible, never plain text. Agent passwords must be 12 to 256 characters, enforced both on the administrator's create-agent screen and on an agent's own profile page, so a weak password cannot be introduced through the side door.
The install ships with demo accounts so you can evaluate immediately. Because those credentials are published in the download, the dashboard shows a warning banner until the password is changed — and the banner clears by itself once it is.
Authorization boundaries
Every management endpoint requires a signed token. An unauthenticated request gets 401, and so does a tampered token — not a partial response. Agent-level accounts receive 403 on administrative actions: creating or deleting agents and departments, editing settings, reading the audit log.
Responses are filtered by role as well as blocked by it. An administrator listing agents sees email addresses and admin flags; a non-admin agent listing the same roster sees only display names and IDs.
Abuse and exposure limits
Visitor-facing endpoints are rate limited per IP, so a script pointed at your widget is throttled rather than left to hammer the database. Failed sign-ins are throttled on the same counter that governs two-factor codes, so neither passwords nor codes can be brute-forced.
The server sets a strict Content-Security-Policy alongside X-Content-Type-Options, X-Frame-Options, Referrer-Policy and X-Permitted-Cross-Domain-Policies on every response.
Visitor input is never trusted
Everything a visitor types is escaped before it reaches an agent's screen. Markup pasted into a chat is shown as text, not rendered, in both the browser console and the widget. Links become clickable only after the destination is checked, and the visible label always matches where the link actually goes.
If your portal pre-fills the chat form with a signed-in customer's name, the server still treats that as untrusted input — convenience for the visitor, never a substitute for your own authentication.
Verify it yourself
The download includes a verification checklist for proving the server, database, licence, dashboard and widget are genuinely working. A few checks you can run in the first ten minutes:
- Open
/health/ready and confirm it names which dependency is failing rather than returning a blank error.
- Request an admin API endpoint without signing in and confirm you get 401.
- Sign in as the seeded agent account and confirm settings and the audit log return 403.
- Send bold markup from the widget and confirm the agent sees the characters, not formatting.
- Change the seeded password and watch the dashboard warning banner clear.
Security starts with ownership.
ZChat is built for organizations that want modern support software without handing core support traffic to a hosted middleman.