Security risks of adding a chatbot to your website

Chat widgets and AI assistants can answer FAQs and route support. They also add a new place to collect personal data, run third-party JavaScript, and (for LLM bots) accept hostile instructions from visitors or page content.

You do not need to avoid chatbots entirely. You do need to treat them like any other high-privilege integration: know what they store, who hosts them, and what they are allowed to do.

1. Over-collection and data exfiltration

A bot that asks for order IDs is useful. A bot that also asks for full card numbers, passwords, or government IDs is a liability, whether the prompt was yours or an attacker who changed the config.

Risks:

• Transcripts stored at a SaaS vendor you have not vetted
• Staff accounts on the bot dashboard without MFA
• Compromised admin settings that widen questions mid-conversation

Mitigations: collect the minimum, forbid payment and password fields in bot flows, lock the vendor admin with MFA, and review transcripts for odd new prompts. Customer data habits: protecting customer data.

2. Prompt injection and “helpful” overrides

LLM bots read instructions from the developer and from user input. Attackers craft messages (or hide text in pages/files the bot can see) that say “ignore previous rules” or “reveal your system prompt.”

That can leak internal notes, change tone into brand damage, or push users toward phishing links. Treat untrusted input as hostile. Limit tools the bot can call (refund APIs, CRM writes). Do not give the bot raw database credentials or WordPress administrator powers.

3. Poisoned or drifting behavior

If you fine-tune or continuously feed the model on user conversations, bad actors can try to bias answers over time. Even without training, a changed knowledge file or CMS snippet the bot indexes can alter replies.

Control which documents are in the knowledge base. Review changes. Spot-check answers for policy and safety the same way you would spot-check a junior support hire.

4. Third-party scripts and supply chain

Most WordPress chatbots are a plugin plus a remote script. That is plugin supply chain risk and classic front-end risk:

• Outdated plugin with a known hole
• Vendor script changed upstream
• XSS in the widget surface
• Skimmer-style malware living next to a “support” iframe on checkout pages

Prefer maintained vendors, load scripts only where needed (not on checkout if avoidable), and keep WordPress and the plugin updated. Related: how to tell if a plugin is secure and the vulnerabilities hub.

5. Open-source models and DIY stacks

Self-hosting an LLM or grabbing a random GitHub bot can be fine for experiments. For production customer chat, you inherit patching, auth, logging, and abuse control. Popular projects get attention from researchers and attackers alike. Budget time for updates or use a vendor who does.

What “encryption” actually buys you

HTTPS to the vendor is table stakes. It protects traffic in transit to that service. It does not mean the vendor cannot read transcripts, nor that a compromised WordPress admin cannot change the widget. Use HTTPS everywhere on your site (SSL basics), then focus on vendor contracts, retention settings, and admin least privilege.

Practical launch checklist

• Written rules: no cards, no passwords, no government IDs in chat
• Vendor MFA, SSO if available, few admin seats
• Data retention and region settings you accept
• Bot cannot perform privileged actions without human approval
• Plugin and script limited to pages that need them
• Monitoring for defacement, odd new CTAs, and checkout script changes
• WordPress hardening still in place (checklist, hardening guide)

Chatbots are another support channel with a bigger blast radius than a mailto link. Ship them with the same caution you use for payment plugins: least data, least privilege, and a vendor you can fire.