Mass assignment is security risk where user can create/update data attributes that is not allowed to update.
Here is an example. Imagine application that registers your employees working hours. When user logs in it sets start time, and when it logs out it sets end time. Pretty simple feature.
User login form has username/password input fields. Imagine that user can temper its login timestamp using login request. How? Your employee friend is skilfull tester, and he knows how to send POST request using Postman tool. Using Chrome developer tools he/she finds out the login attributes and now he tries to guess login timestamp attribute:
- create_time, …
Those names set with date values in the past (he/she wants his friend to work less) are sent using curl (no need to know cookie!). Heuristic to know when correct time attribute is guessed is very simple. There is another url endpoint, or even login response, that will return login time.
How is that possible!? Ruby on Rails got its popularity because is has a lot of default features that made developer work much easier. One of those features is to automatically accept all http request input parameters that match to available ORM (object relational model) object attributes.
Creation timestamp is an example of attribute that should be set by application, not the user input.
Remember, never trust the user input. And hacker loves default framework features.
Ruby on Rails in current version does not allow mass assignment. Every input parameter must be listed in
method in order to be accepted by ORM.
Using super power tool grep, you should search your Rails codebase for this:
grep -H -r 'permit' * | less
Using your knowledge about the application, you need to conclude (look ma, no automation here!) are those parameter allowed to be listed in permit method in the first place.
I also strongly advise communication with your developers 🙂 in order to make the decision.