Strong parameters in Ruby on Rails - Step-by-Step Execution

Concept Flow - Strong parameters

Receive HTTP request with params

↓

Call controller action

↓

Invoke strong_params method

↓

Permit only allowed keys

↓

Return filtered params

↓

Use filtered params to create/update model

↓

Respond to client

Strong parameters filter incoming request data to allow only safe keys before using them in model operations.

Execution Sample

Ruby on Rails

def create
  user = User.new(user_params)
  if user.save
    render json: user
  else
    render json: user.errors
  end
end

def user_params
  params.require(:user).permit(:name, :email)
end

This code creates a new user only with permitted name and email parameters from the request.

Execution Table

Step	Action	Input Params	Permitted Keys	Filtered Params	Result
1	Receive request	{user: {name: 'Ana', email: '[e-mail]', admin: true}}	N/A	N/A	Params received
2	Call user_params	{user: {name: 'Ana', email: '[e-mail]', admin: true}}	:name, :email	{name: 'Ana', email: '[e-mail]'}	Filtered params returned
3	Create User.new	{name: 'Ana', email: '[e-mail]'}	N/A	N/A	User object initialized with safe params
4	Save user	User object	N/A	N/A	User saved if valid
5	Render response	User saved	N/A	N/A	JSON response sent to client

💡 All params except :name and :email are filtered out to prevent unsafe mass assignment

Variable Tracker

Variable	Start	After Step 2	After Step 3	Final
params	{user: {name: 'Ana', email: '[e-mail]', admin: true}}	{name: 'Ana', email: '[e-mail]'}	User object with name and email	User saved or errors
user	nil	nil	User object initialized	User saved or errors

Key Moments - 2 Insights

Why does the admin key not get assigned to the user?

Because in step 2 (user_params), only :name and :email are permitted, so :admin is filtered out and never assigned.

What happens if the required :user key is missing in params?

The require(:user) call raises an error, stopping execution early to prevent unsafe operations.

Visual Quiz - 3 Questions

Look at the execution table at step 2, what keys are included in filtered params?

A name, email, and admin

B name and email

C only admin

D no keys

💡 Hint

Check the 'Filtered Params' column at step 2 in the execution_table

At which step does the code prevent unsafe keys from being assigned to the user?

A Step 2

B Step 1

C Step 3

D Step 4

💡 Hint

Look at the 'Action' column where filtering happens in the execution_table

If we add :admin to the permit list, what changes in the execution table at step 2?

A Params will be empty

B Filtered params will exclude admin key

C Filtered params will include admin key

D Code will raise an error

💡 Hint

Consider how permit affects filtered params in step 2 of the execution_table

Concept Snapshot

Strong parameters filter incoming request data.
Use params.require(:model).permit(:allowed_keys).
Only permitted keys pass to model.
Prevents unsafe mass assignment.
Raises error if required key missing.
Always whitelist keys you trust.

Full Transcript

Strong parameters in Rails protect your app by filtering incoming request data. When a controller action receives params, it calls a method like user_params that requires a key (like :user) and permits only certain keys (like :name and :email). This filtering removes any extra keys, such as :admin, preventing unsafe assignment to the model. If the required key is missing, Rails raises an error to stop unsafe operations. This way, only safe data is used to create or update records, protecting your app from malicious input.

Practice

1. What is the main purpose of using strong parameters in a Rails controller?

easy

A. To speed up database queries

B. To style the HTML output

C. To filter and allow only permitted attributes from user input

D. To handle user authentication

Solution

1. Step 1: Understand the role of strong parameters

   Strong parameters are used to control which attributes can be set through forms or API requests.

2. Step 2: Identify the security purpose

   This filtering prevents unwanted or harmful data from being saved, protecting against mass assignment vulnerabilities.

3. Final Answer:

   To filter and allow only permitted attributes from user input -> Option C

4. Quick Check:

   Strong parameters = filter input [OK]

Hint: Strong parameters filter input data to keep app safe [OK]

Common Mistakes:

• Thinking strong parameters speed up queries
• Confusing with styling or authentication
• Ignoring security risks of mass assignment

2. Which of the following is the correct syntax to permit the name and email attributes inside a user_params method?

easy

A. params.require(:user).permit(name, email)

B. params.permit(:user).require(:name, :email)

C. params.permit(:name, :email).require(:user)

D. params.require(:user).permit(:name, :email)

Solution

1. Step 1: Recall the correct order of methods

   The correct pattern is to first require the parent key, then permit the allowed attributes.

2. Step 2: Check the syntax for symbols

   Attributes must be symbols (with colon), so :name and :email are correct.

3. Final Answer:

   params.require(:user).permit(:name, :email) -> Option D

4. Quick Check:

   require then permit with symbols = C [OK]

Hint: Use require first, then permit with symbols [OK]

Common Mistakes:

• Swapping require and permit order
• Using attribute names without colons
• Calling permit before require

3. Given this controller code snippet:

def create
  user = User.new(user_params)
  if user.save
    render json: user
  else
    render json: user.errors
  end
end

def user_params
  params.require(:user).permit(:name, :age)
end

What happens if the incoming params include { user: { name: "Alice", age: 30, admin: true } }?

medium

A. The entire user hash is rejected

B. The admin attribute is ignored and not set on the user

C. An error is raised because admin is not permitted

D. The admin attribute is saved as true

Solution

1. Step 1: Understand permit filtering

   Only :name and :age are permitted, so admin is filtered out.

2. Step 2: Check behavior on extra params

   Extra keys are ignored silently, no error is raised, and only permitted attributes are assigned.

3. Final Answer:

   The admin attribute is ignored and not set on the user -> Option B

4. Quick Check:

   Unpermitted keys are ignored = D [OK]

Hint: Unpermitted keys are ignored, not saved or error [OK]

Common Mistakes:

• Expecting unpermitted keys to be saved
• Thinking unpermitted keys cause errors
• Assuming entire params rejected

4. Identify the error in this user_params method:

def user_params
  params.permit(:name, :email).require(:user)
end

medium

A. require should be called before permit

B. The method should use fetch instead of require

C. The attributes should be strings, not symbols

D. There is no error; the code is correct

Solution

1. Step 1: Recall correct method order

   In strong parameters, require must be called first to get the nested hash.

2. Step 2: Understand method chaining

   Calling permit before require causes an error because permit is called on the whole params, not the nested hash.

3. Final Answer:

   require should be called before permit -> Option A

4. Quick Check:

   require before permit = A [OK]

Hint: Always call require before permit in strong params [OK]

Common Mistakes:

• Swapping require and permit order
• Using strings instead of symbols (not an error)
• Thinking fetch replaces require

5. You want to allow nested attributes for a user's profile with bio and avatar_url. Which user_params method correctly permits this nested data?

hard

A. params.require(:user).permit(:name, profile: [:bio, :avatar_url])

B. params.require(:user).permit(:name, :profile => :bio, :avatar_url)

C. params.require(:user).permit(:name, :profile: [:bio, :avatar_url])

D. params.require(:user).permit(:name, :profile, :bio, :avatar_url)

Solution

1. Step 1: Understand nested attributes syntax

   To permit nested hashes, use a hash with the key and an array of permitted keys inside permit.

2. Step 2: Check each option's syntax

   params.require(:user).permit(:name, profile: [:bio, :avatar_url]) correctly uses profile: [:bio, :avatar_url]. params.require(:user).permit(:name, :profile => :bio, :avatar_url) and C have syntax errors or wrong hash style. params.require(:user).permit(:name, :profile, :bio, :avatar_url) permits keys at top level incorrectly.

3. Final Answer:

   params.require(:user).permit(:name, profile: [:bio, :avatar_url]) -> Option A

4. Quick Check:

   Nested permit uses hash with array = A [OK]

Hint: Use hash with array for nested attributes in permit [OK]

Common Mistakes:

• Passing nested keys as separate symbols
• Using wrong hash rocket syntax inside permit
• Permitting nested keys at top level