Embedding a website assistant usually means pasting one line of code into your site. It takes a minute, which is exactly why it gets less thought than it deserves.
That line loads a script from someone else's server, and that script runs inside your pages alongside your contact forms, your checkout and your customers' browsers. You would not hand a stranger the keys to the shop because the lock was easy to open.
None of this means chat widgets are dangerous. It means chatbot security on a website comes down to a few plain questions: what the script can reach, where the conversation data goes and who can see it. You can answer most of them in an afternoon.
What a script tag actually does
When a browser loads your page and finds a third-party script tag, it downloads that code and runs it with the same access as your own code on that page. There is no sandbox by default. The script could, in principle, read the page, change what is shown, or send data elsewhere.
In practice, a chat widget uses that access to draw a button, open a chat window and send messages back and forth to the vendor's servers. The point is not that vendors misbehave. It is that third-party script security rests on trust in the vendor and their own security practices, because a compromise on their side would reach your pages too.
That leads to two sensible habits:
- Only embed from vendors you would trust with your site: the same bar you would apply to a payment provider or analytics tool.
- Load the script from the vendor's official address: do not copy the code into a random file on your server where it will never be updated, and do not use a version someone sent you by email.
Where to put the widget and where not to
The simplest way to reduce risk is to keep the assistant off pages where it adds nothing. Visitors rarely need a sales or support chat while typing a card number.
| Page type | Embed the assistant? | Reasoning |
|---|---|---|
| Home, services, pricing, contact | Yes | This is where questions and enquiries happen |
| Blog and guides | Usually | Readers often have follow-up questions |
| Checkout and payment pages | Avoid | Nothing to gain, and payment pages deserve the fewest scripts |
| Login, password reset, account settings | Avoid | Keep sensitive flows as lean as possible |
| Admin or staff areas | No | No visitor benefit at all |
| Patient or client portals | Only after checking your obligations | Depends on what the portal holds and your sector's rules |
If your site runs on a builder that inserts code on every page, check whether it lets you exclude certain pages. Most do.
Where the conversation data goes
Once a visitor types a message, it leaves their browser and travels to the vendor. Four questions tell you most of what you need to know about how it is handled.
- Is it encrypted in transit? Every modern service should use HTTPS for the widget and the messages. If the answer is anything but a straightforward yes, stop there.
- What is encrypted at rest? Ask specifically about stored credentials, such as API keys or integration secrets, as well as conversations.
- How is my data separated from other customers? You want to hear that each account's data is isolated, so another business using the same service cannot see your conversations or leads.
- Can I control how long conversations are kept? A configurable retention window lets you delete old transcripts on a schedule rather than keeping everything forever.
For reference, SpideyChat encrypts traffic in transit, encrypts stored credentials at rest, isolates data per account and lets you configure conversation retention windows. It does not hold SOC 2 or ISO 27001 certification. If your contracts or sector require either, that matters, and you should know it before you build anything. More on the retention question is in how long to keep chat transcripts.
Webhooks, integrations and the credentials behind them
Security questions often stop at the widget. The more interesting risk sits one step further along, where the assistant sends leads or tickets to other systems.
If you switch on a webhook that posts lead details to Zapier, Make, a CRM or Slack, you are creating a new path for customer data. A few checks keep that path tidy:
- Send only what the receiving tool needs: a Slack alert does not need the full transcript.
- Use a dedicated endpoint: create a webhook URL for the assistant rather than reusing one shared across unrelated automations.
- Rotate secrets when staff leave: anyone who set up the integration may have copied the URL or key.
- Check where the data lands: a Slack channel visible to the whole company is a different thing from a CRM with access controls.
The integrations page lists what connects and how. The walkthrough on sending leads to a CRM with webhooks covers setup.
Access on your side of the fence
Many chat data problems start inside the business, not at the vendor. The inbox holds names, phone numbers and sometimes details people should not have typed.
Work through who has access. Give team seats to the people who need them and remove them when someone leaves. Use strong, unique passwords, and two-factor authentication where it is offered. If you run several assistants for different brands or clients, check that the right people see the right inboxes and nobody else.
Also tell the assistant, in its persona instructions, not to ask for payment details, passwords or sensitive personal information, and to warn visitors not to share them. That will not stop every visitor, but it reduces how often such details end up stored at all.
Questions to put to any vendor in writing
Before you commit, send these in an email and keep the reply. Vague answers are an answer of sorts.
- Can I restrict which domains the widget runs on, so someone cannot copy my embed code onto their own site and use up my message allowance?
- Where is conversation data stored, and is it encrypted at rest?
- How is my account's data isolated from other customers?
- Which certifications do you hold today, and can you share evidence?
- Can I set a retention period and delete conversations on request?
- What happens to my data if I cancel?
- Who on your side can access my conversations, and why?
- How will you tell me about a security incident that affects my data?
A vendor who answers each of these plainly, including saying "we don't have that" where true, is usually a better bet than one who responds with a badge collection and no specifics.
Your next step
Make a list of every page on your site and mark each one yes, no or check, using the table above. Send the vendor questions before you paste the embed code, not after. Then read the GDPR checklist for a website assistant if you handle data from visitors in the UK or EU, because security and data protection overlap but are not the same job.