Why attachments earn their keep
A screenshot ends an argument. Ten messages of “what exactly does the error say?” collapse into one image, and the agent sees the browser, the operating system, the URL and the actual wording of the failure all at once. For technical support in particular, the ability to accept a file is the difference between a five minute conversation and a twenty minute one, and visitors reach for it naturally because it is what they do everywhere else. Turning uploads off entirely is a real cost, not a free safety measure, and it is worth being clear-eyed about that before deciding.
The other half of the truth is that an upload is an unsolicited file from an anonymous stranger, arriving into a tool your support team has open all day. That is a category of risk you would never accept casually by email, and it deserves the same thought here even though the chat window makes it feel informal.
Decide what you accept before someone asks
The useful default is narrow: images and PDFs cover the overwhelming majority of genuine support cases, and almost nothing else does. Executables, scripts, archives and office documents with macros have essentially no legitimate reason to arrive through a chat widget, and each of them is a well-worn delivery route for something you do not want. If you find yourself needing a broader set, that is usually a sign the conversation should move to a channel built for it rather than a sign the widget should accept more.
Set a size ceiling too. It is not primarily a security control — it is a way to stop a single upload monopolising the conversation and to keep an accident from filling storage. A limit generous enough for a phone screenshot and mean enough to reject a video is about right, and the error message should say what the limit is rather than failing silently, because a visitor who does not know why the upload failed will simply try again with the same file.
Never trust the extension
The filename is chosen by whoever sent it, which means it is a claim rather than a fact. A file called invoice.pdf can be anything, and the extension is the single easiest thing in the whole chain for an attacker to control. Filtering on the name alone is theatre; what matters is what the file actually is and what your systems do with it when it arrives.
The same applies to the name itself, not just its ending. Filenames arrive as untrusted text and they get displayed in the agent console, written to storage and sometimes included in a transcript or a notification email. A name containing markup, path separators or a very long run of characters is a classic way to probe for a weakness downstream. Treat the filename as data to be escaped and sanitised, never as an instruction about where something goes.
Teach agents the one rule that matters
Whatever your platform does, the last line of defence is the person who receives the file, and the rule is short enough to remember: do not open an attachment from a chat visitor on the machine you use for everything else, unless you asked for it and it is what you asked for. Most support attachments pass that test easily — the agent said “can you send a screenshot?” and a screenshot arrived. The ones that fail it are unmistakable: a file nobody requested, arriving early in a conversation, with a name designed to make you curious or anxious.
Give agents somewhere to go with the suspicious ones. If the only options are open it or ignore it, the file gets opened, because ignoring a customer feels rude and support people are not built for that. A named person or channel to forward it to costs nothing to set up and changes the outcome, and it also gives you visibility into how often it happens.
Watch for the file that is a social engineering prop
Not every dangerous attachment is dangerous because of what is inside it. A common pattern is entirely benign as a file and entirely manipulative as a message: a screenshot of an account page, an image of an identity document, a receipt, offered as proof of who the sender is. The file does nothing at all except make the agent feel that verification has happened, and then the real request arrives — change the email on the account, resend the licence key, confirm the address on file.
An uploaded image proves nothing about the person who uploaded it. It can be edited, borrowed, or taken from a real customer whose details were exposed somewhere else entirely. A public chat widget is not an authentication channel and an attachment does not make it one; the correct move when a request needs identity is to move to a path where identity actually exists, not to accept a picture as a substitute for it.
Think about where the file lives afterwards
Uploads outlive the conversation. They sit in storage, appear in transcripts, and follow whatever retention rule you have set for chat data — and if you have not set one, they follow no rule at all and simply accumulate. That matters most when a visitor uploads something you never asked for and would rather not hold: an identity document, a bank statement, a photo with more in the frame than they realised.
Bring attachments explicitly into your retention policy rather than letting them ride along invisibly, and check that whatever you tell people about deleting their data is true of files as well as messages. If an agent receives something that clearly should not have been sent, the right response is to deal with it in the moment — note that it was removed, tell the visitor what happened, and continue — rather than leaving it in place because deleting things feels irreversible.
Make the link between two places you already have policies
Attachment handling tends to fall between two stools. The security policy covers email attachments and endpoints; the support policy covers tone and response times; and nobody wrote down what happens when a stranger uploads a file into the chat widget. It is worth one short paragraph in whichever document your agents actually read, saying what the widget accepts, what to do with something unexpected, and who to send it to. Written down once, it survives staff turnover; explained verbally, it lasts as long as the person who heard it.
How MyLiveChat fits
MyLiveChat supports file transfer in chat, and it is worth treating that as a setting to make a decision about rather than a feature to leave on by reflex. Decide whether your conversations genuinely benefit from uploads, and if they do, tell agents in writing what to do with a file they did not ask for. Whatever you decide, include chat attachments in your transcript retention thinking rather than letting them accumulate outside it, and remember that the widget is open to anyone on your website — the person uploading is exactly as verified as the person typing, which is to say not at all.
Attachments arriving from a messaging channel take an entirely different path from files uploaded in the widget. Why a WhatsApp photo opens only in your ticket covers the allow list, the size ceiling and the rule that decides what displays and what downloads.