Security precautions

NEVER run Flood with root or users with NOPASSWD sudo privilege.
Deny Flood write access and ownership to Flood's (program) files.
- Flood only needs to have r/w access to the runtime directory (--rundir) and download destinations.
- This prevents an attacker from overwriting Flood's control flows and executing arbitrary codes.
Use --allowedpath to specify paths allowed for file operations.
Prohibit PHP or other dynamic pages from executing inside Flood directory (if static assets are served directly via web server).
Use SSL to defeat on-path attackers. Your password is in cleartext during authentication. If you don't use SSL, makes sure that the connection path is not vulnerable to eavesdropping. Plus, don't (re)use your favorite password(s).
Flood's in-house authentication system is thoroughly tested, and maintainers pledge to address any security issues as soon as possible, should any arise. However, in high-stake environments, if you prefer to use a more battle-hardened solution such as HTTP Basic Auth, you can use disableUsersAndAuth to avoid duplicate authentication.
Avoid exposing Flood to Internet unless you are sure that you got security right.

NEVER run rTorrent with root or users with NOPASSWD sudo privilege.
NEVER expose rTorrent's SCGI interface to Internet (or even local network).
Avoid using SCGI host:port mode of rTorrent. It may allow local privilege escalation (to rTorrent's account) as ports can be still accessed by any local program even if you use 127.0.0.1 as listening host.
Use SCGI socket mode of rTorrent. Only allows Flood to access the socket.
- Flood and rTorrent need to share a user or a group. (or use ACL/SELinux, not covered here)
- If same user, permission can be 700. If same group, permission can be 770.
- jesec/rtorrent has a secure default (0700). For old rTorrent versions, append command like execute.nothrow = chmod,770,(cat,/path/to/rtorrent.sock).

Container technologies can reduce attack surface and restrict scope of access. However, you should still pay attention to security. Intruders do NOT need to break out of container (or even get root access) to initiate cryptomining, spam email sending or using the compromised instance as proxy to attack your internal network.
Be aware! When you ask Docker to expose a port (e.g. -p 3000:3000), by default, Docker exposes such a port to 0.0.0.0 (aka Anywhere). Additionally, by default, Docker "helpfully" creates firewall/iptables rules for you, which may override your existing firewall configurations.
- Read Docker and iptables, Container networking carefully.
- Use explicit address binding like -p 192.168.1.2:3000:3000 if you intend to expose to local network only.
Try the new distribution-less (distroless) Docker image. Even if other security measures are breached, without shell, package manager, libc or even coreutils (base64, cp, mv, etc.), intruders would find it extremely difficult to perform any malicious action. Only highly sophisticated attackers with tailored toolkits have a chance in such an environment.
- ADVANCED: To go one step further, mount data directory and runtime directory with noexec, nodev and nosuid. Combined with distroless environment and --allowedpath, it is simply impossible to execute unauthorized programs, as there is no place that is writable and executable at the same time.

NAT (Network Address Translation) commonly seen in IPv4 networks is NOT a security feature. Yet, admittedly, for those of us who are accustomed to concepts like "one home, one router, one shared public IP address" and "port forwarding", NAT played a crucial rule in safeguarding the security of our local networks.
IPv6 changed that, however. Every machine with an IPv6 address is presumed to be Internet-accessible. As a result, if your home network is IPv6-enabled:
- DO NOT assume that exposing to 0.0.0.0 or ::/0 is local network only.
  - Services can be unexpectedly exposed to Internet.
  - Port forwarding is NOT needed for IPv6.
- Be extremely vigilant about address bindings and firewall configurations.
  - Explicitly bind a home-only service to local network address (e.g. 192.168.1.2).
  - Explicitly block outside IPs from accessing services.

Create a cronjob in /etc/cron.d that spawns a shell.
Add any ssh key to /home/$USER/.ssh/authorized_keys and login over SSH.
Overwrite /home/$USER/.bashrc to execute commands on the next login of the user.
Overwrite code of Flood itself which will execute the next time it is restarted.
Overwrite rTorrent's configuration (.rtorrent.rc) to expose SCGI interface to Internet.

TL;DR: It is worse than SSH/RD login to rTorrent's account.
rTorrent's SCGI interface IS a SHELL. APIs like execute.nothrow = allow a user to execute ANYTHING at rTorrent's privilege.
Scheduling interfaces of rTorrent allow cron-like scheduling. It can allow persistent hard-to-detect backdoors.
rTorrent itself has capability to download files. Attackers don't need to use utilities like curl or wget to download external malicious executables.

Provide feedback