Skip to the content.
« TLS Vulnerabilities

Information Leakage

Elixir and Erlang standard library

Please refer to the Secure Coding and Hardening Guidelines chapter on Sensitive Data for more information about features available in the Elixir and Erlang standard library for reducing the risk of accidental data leakage. It explains how to customize the way inspect renders a struct, wrap secrets in closures, and filter sensitive data from stacktraces, among other things.

Parameter filter in Phoenix logger

Phoenix by default logs request parameters for every request. For routes that accept sensitive data, such as user sign-in, it will be necessary to filter out those values. This can be done through the Phoenix.Logger configuration:

config :phoenix, :filter_parameters, ["password", "secret"]

By default only parameters that contain the word “password” are filtered. A stronger form of filtering, using an allow-list rather than a deny-list, can be used instead.

Phoenix socket messages

In a LiveView application, form data is submitted over a Phoenix socket, wrapped in a Phoenix.Socket.Message struct. If the socket process dies unexpectedly, the message that triggered the error is logged as part of the process termination report. Unfortunately the Phoenix logger parameter filter does not prevent sensitive data from being written in this context.

One way to reduce the risk of data leakage would be to implement the Inspect protocol for the Phoenix.Socket.Message struct, as shown here.

Redacting fields in Ecto schemas

When defining Ecto schemas, individual fields can be marked with redact: true, to replace the value of those fields with **redacted** when inspecting. This applies not only to the schema’s structs, but also Changesets that wrap it: changes to the redacted fields are also automatically redacted when the Changeset is inspected.

Next: Supply Chain Vulnerabilities »