I’m curious what kind of malicious scenarios should be considered with LiveView. LiveView transfers computation and state to the server, which seems to open up attack surface. For example, if a client cannot/will not receive messages fast enough, that increases memory usage on on the server?
Every websocket connection that liveview uses is a single process. Processes have (as per current documentation) 327 words of memory allocated to them, if you exceed that threshold the process crashes and the memory is freed.
The exception is when it comes to things like big binaries, those are stored in a different place and referenced from the process. This is a possible vector of attack as it is possible to create memory leaks with binaries that are not garbage collected correctly, but at the same time this is trivial to fix if detected and it highly depends on the implemented logic.
This answer, as I read it, is potentially misleading. The heap of the liveview process is not constrained to its initial size during its lifetime, but may grow.
Regarding denial-of-service attacks, this would depend on how the underlying HTTP adapter (cowboy or bandit) managed flow control over the underlying socket, but if you wanted to be conservative, you could set your own heap limit.
My bad, the number above points to the initial heap size allocated. The maximum heap size for a process is (or at least can be) limited nonetheless, with the max_heap_size
option:
{max_heap_size, Size}
- Sets themax_heap_size
process flag. The defaultmax_heap_size
is determined by command-line argument+hmax
in erl. For more information, see the documentation ofprocess_flag(max_heap_size, Size)
.