Mass assignment protection out of the box

Skip to first unread message

Jun 23, 2018, 5:16:32 AM6/23/18
to phoenix-talk

I am proposing this feature, based on Ruby on Rails permit parameter.

Here is explanation.

In Ruby on Rails, if permit is not called on parameters, database items can not be created/updated.
With permit, developer sets which parameters could be updated.
E.g. on user registration that could be :email, :password, :username.

So if hacker tries to update all possible database attributes using curl, e.g. for user registration token activation time, this would fail.

In phoenix, call to cast method on changeset, should be made mandatory.

Regards, Karlo.

Chris McCord

Jun 23, 2018, 2:30:19 PM6/23/18
Phoenix uses Ecto to handle user input by default, and Ecto requires you to pass the cast-able fields when calling cast, so this is already part of the contract.

You received this message because you are subscribed to the Google Groups "phoenix-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To post to this group, send email to
Visit this group at
To view this discussion on the web visit
For more options, visit

Jun 23, 2018, 3:14:54 PM6/23/18
to phoenix-talk

My idea was to make calling cast method mandatory.
That Ecto refuses to do any model operation if changeset was not created using cast method.

Is this possible to do?


Regards, Karlo.

Michał Muskała

Jun 24, 2018, 2:54:46 AM6/24/18
to phoenix-talk
I would say that this already happens. The only way you could "bypass" cast is by building the changeset/struct field-by-field but then you filter the fields you allow already. There has to be some intermediary step (be it cast or some other filtering), because the params come with string keys, but structs and change sets accept atom keys. It's not possible to just pass whole params to the database.

Reply all
Reply to author
0 new messages