No. The Memcached project's own configuration page says it spends little effort on defending itself from random internet connections, so you must not expose it directly to the internet or to untrusted users. SASL authentication helps but should not be fully trusted. Keep it on a private network or a local socket.
What the project says
The Memcached wiki states plainly that Memcached does not put much, if any, effort into being defensible against random internet connections. It then gives the rule: do not expose it directly to the internet, or otherwise to any untrusted users. It adds that SASL authentication helps, but should not be totally trusted.
That is a strong statement from the maintainers, and it sets the design. A cache sits behind your application, and the application is the layer that talks to untrusted people.
Defaults worth knowing
| Setting | What the documentation says |
|---|---|
| Transport | Since 1.5.6 Memcached defaults to listening on TCP only |
| UDP | Defaults to off since 1.5.6, set with the U option, and 0 disables it |
| Bind address | The l option binds to specific interfaces or addresses |
| Unix socket | The s option restricts access to a local user, and disables TCP and UDP |
| Connections | Maximum concurrent connections defaults to 1024 |
If your packages or container images are older than 1.5.6, check whether UDP is on. Do not assume the modern default.
Steps to lock it down
- Find every Memcached instance and its version. Include the ones started by a framework or a Docker Compose file.
- Bind to a private interface with the l option. Binding to all interfaces on a host with a public address is the classic mistake.
- Turn UDP off explicitly. Even where it is already the default, writing the setting down means a later upgrade or template change does not quietly turn it back on.
- Firewall the port so that only application servers can connect.
- If the cache and the application run on the same host, use a Unix socket and remove the network listener entirely.
- If you enable SASL, treat it as one layer of several, not as the control that makes exposure acceptable.
- Decide what you store. Anything cached can be read by anyone who gets access to the instance, so avoid keeping credentials, tokens or personal data there without a plan.
What not to cache
A cache feels disposable, which is why people put things in it that they would never put in a database: session tokens, full user records, API responses with private fields. If the instance is reached by the wrong person, that data goes with it. Decide which data classes may enter the cache, and set short expiry times for the sensitive ones.
How Memcached compares in principle
Redis takes a similar position: its documentation says it is designed for trusted clients inside trusted environments. Both projects expect you to place them behind your application and control access at the network layer. The practical difference is that Redis offers named users and per-command permissions through ACLs, so see How do you block dangerous Redis commands if you run both.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a recurring check could tell you a service moved onto a public address.
Safeguard's asset discovery helps you find services you did not know were running, and the free scan checks your code and dependencies.
Quick check
Does enabling SASL make it fine to put Memcached on a public IP?
No. The Memcached wiki says SASL helps but should not be totally trusted, and that the service must not be exposed directly to the internet.
How do I make Memcached reachable only from the same machine?
Use a Unix socket with the s option, which disables TCP and UDP, or bind to the loopback address.
Sources
Last reviewed: 19 October 2026.
