I once tried to build just such a project for an Elixir/Phoenix security training, but for reasons mentioned by @hauleth it turned out to be quite difficult to translate the existing projects to Elixir: in many cases I had to explicitly bypass the default protections of Plug/Phoenix/Ecto to introduce a vulnerability, so the whole thing turned out to be quite contrived.

That’s not to say Phoenix/Elixir projects don’t have security vulnerabilities, and I guess it would be interesting to see what a Phoenix/Elixir TOP 10 would like like. My guess is there would not be much overlap with OWASP TOP 10.

xmerl is vulnerable to XXE attacks by default, and in some modes also to DoS by atom exhaustion; see here for mitigations.

See here and here for mitigations.

Phoenix’ default protections against XSS work well in specific contexts, but if you inject variables outside of the primary page HTML context you may find that the default protections are not sufficient. Keep in mind that the escaping rules vary depending on the exact context where the data is injected, and Phoenix only covers the most common ones. For other languages there are sophisticated XSS prevention frameworks that actually detect the injection context and adapt the escaping rules accordingly.

Just beware that there are subtle ways in which (de)serialization (with :erlang.binary_to_term & co) can lead to severe vulnerabilities in Erlang/Elixir apps; see here.

If I had some time I’d love to try and create a deliberately vulnerable application, perhaps not following OWASP TOP 10 but rather showcasing some of the issues mentioned above. It would make for a great training resource.

Many of these are at least hard in Elixir:

1. If you use Ecto.Query then SQL injections are hard.
2. This is going to be resolved by the auth generation library that was announced. However if you use proper auth with cookies and Comeonin, then you should be probably good already.
3. This is hard to be checked for automatically.
4. I believe that xmerl is safe against such attacks, but I haven’t checked. Other than that - Phoenix do not support XML by default.
5. Similar to 3.
6. The most important offender there is httpc, but as this is very primitive client, then it is not that commonly used. Another source of problems can be ssl module, by default it uses TLSv1.1 and TLSv1.2, but you should probably change it to 1.2 and 1.3 if you can. Others are highly dependant on the application, but Phoenix could generate endpoints with more secure headers though.
7. Phoenix templates secure against XSS by default. So unless you explicitly make yourself vulnerable, then it should be safe enough.
8. Unless you use :erlang.binary_to_term/{1,2} on unsafe inputs then there are no built-in unsafe serialisation formats. And default JSON decoder (Jason) is safe enough unless you explicitly ask for making map keys atoms.
9. There is work for that by @voltone and EEF Security WG with generators for Cyclone DX SBoM and Sobelow
10. It is in the works by EEF Observability WG with adding more tools for proper observability (telemetry, OpenTelemetry, etc.) and logging (integration of Erlang’s logging facilities in Erlang’s logger, Elixir’s Logger is mostly completed, lager is still in the works).

Additionally a lot of Erlang/Elixir specific issues can be detected by already mentioned Sobelow project.

Recently launched: Potion Shop is an intentionally vulnerable Elixir/Phoenix application, for teaching developers about web application security. This project is vulnerable to common vulnerabilities such as XSS, CSRF, and RCE.

One more thing…

Elixir’s System.cmd/2,3 provides protections against OS command injection, but I sometimes see people use Erlang’s :os.cmd/1,2, which does not; see here…