Also, GitHub - mirego/mix_audit: 🕵️‍♀️ MixAudit provides a mix deps.audit task to scan a project Mix dependencies for known Elixir security vulnerabilities · GitHub can provide some help.
c4710n
realcorvus
Using Sobelow and mix_audit were already mentioned, both are great tools.
If your app takes URLs as user input, then does some HTTP request based on them, you should check for server side request forgery (SSRF) It can lead to very bad security incidents, for example it caused the Capitol One breach. There is an open source Elixir library, SafeURL, to help prevent it.
The EEF publishes secure coding and deployment hardening guidelines. Recently Podium released the Elixir Secure Coding Training as a series of LiveBooks as well.
In my experience, Phoenix discourages you from writing code with common web app vulnerabilities (SQL injection, XSS, CSRF). Security incidents still happen, often due to someone attacking the site with a bot:
- Performing thousands of automated login attempts, using a leaked credential database, to compromise user accounts. This is called credential stuffing, and can be mitigated with 2FA (see NibleTOTP from Dashbit), ensuring password are not being re-used with an Elixir library like ex_pwned, or bot detection.
- Uses a bot to automate new account creation, then attempts hundreds of purchases using stolen credit cards. The goal of the attacker is to figure out which cards work, it’s called a carding attack.
- If your app allows users to send emails through a form, for example a project management tool where you can invite people to a project with a brief message, spammers will use this function to send out scam emails. In addition to your users being upset about the spam, your backend email provider may ban your account over this.
Disclosure, I run Paraxial.io, which is a company that blocks attacks like this. Big companies have anti-bot products as well (Google reCaptcha, Cloudflare bot defense), however I would not recommend them.
There’s a number of open source Elixir libraries that can help as well:
-
PlugAttack, I wrote a blog post on it, great library.
I also publish some security related Phoenix posts on the Paraxial.io blog, for example Detecting SQL Injection in Phoenix with Sobelow. If you have questions about this stuff, but don’t want to reply here, feel free to dm me.
12
jaimeiniesta
Hey there, I use Paraxial and it’s great!
I recently looked at 404s in my logs and found a lot of suspicious requests like these:
Where can I find a more complete list of typical URLs used in exploit scans?
I’m thinking of adding a plug in my app so I can block IPs performing these requests. The idea would be to remember the IP and block it from the plug, and maybe also submit it to a Paraxial’s honeypot. For that, if would be useful to only block them for 24 hours or so, because attackers may be using temporary IPs and I don’t want to ban them forever.
2
arcanemachine
Where can I find a more complete list of typical URLs used in exploit scans?
Just run fail2ban on your server for a couple weeks and check the logs. 
1
krasenyp
You can make use of tools included in your default OS installation. For example, on FreeBSD there’s PF, a firewall, which can easily be integrated with fail2ban, or blacklistd. Not everything should be built into your service.
0
Rob1
I noticed Phoenix project files have database credentials, for example if you Google
phoenix config.exs example
the top result shows putting in a username and password. (It doesn’t actually include one, just a placeholder, but the risk is there of sharing it when sharing a Phoenix project with the world.)
This could possibly be fine for a local application where no one can connect to the database remotely but if you are going to check your Phoenix application into source control, for example to share it with other developers as the example shows, it could make sense to put those values in environmental variables to reduce the risk of sharing your database password, especially for a hosted database solution that isn’t on localhost.
For example I plan to share a complete phoenix app here, my postgresql database will be hosted, so if I shared the app including config file I would end up sharing the admin password to my database.
Instead ChatGPT suggests replacing the lines in config.exs with these lines, I hope it would work:
config :real_world, RealWorld.Repo,
adapter: Ecto.Adapters.Postgres,
username: System.get_env(“DB_USERNAME”),
password: System.get_env(“DB_PASSWORD”),
database: “real_world_dev”,
hostname: “localhost”,
pool_size: 10
Is this correct?
0
Aadmaa
Yes, you would not usually hardcode those values except for in the dev and test environments and that example does show how to get them from Environment Vars. You can also use Dotenvy to use a local .env file, which you can add to .gitignore so it does not get committed. I don’t think you need chatgpt for this one though 
If you make a new app with “mix phx.new,” take a look at runtime.exs. You will see the database URL gets set up with “System.get_env(“DATABASE_URL”)” n the :prod environment, and you’d have to set that environment value for the app to run.
2
al2o3cr
Probably not - using System.get_env in config.exs means that the configuration is read at compile time, not when the system actually starts.
As @Aadmaa points out, the Phoenix generators already output a configuration in config/runtime.exs that uses a DATABASE_URL environment variable to encapsulate user/pass/host/options. That gets loaded at system-start time.
4