Security best practices in Ruby on Rails - Step-by-Step Execution

Concept Flow - Security best practices

User Input Received

↓

Validate Input

↓

Sanitize Input

↓

Use Secure Authentication

↓

Authorize User Actions

↓

Encrypt Sensitive Data

↓

Log Security Events

↓

Respond to Threats

↓

End

This flow shows how Rails handles security step-by-step: input is checked, cleaned, user identity is confirmed, permissions checked, data encrypted, events logged, and threats handled.

Execution Sample

Ruby on Rails

class UsersController < ApplicationController
  before_action :authenticate_user!

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

  private

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

This Rails controller securely creates a user by authenticating, permitting only safe parameters, and handling success or failure.

Execution Table

Step	Action	Input/State	Result/Output
1	Receive POST /users with params	{email: '[e-mail]', password: 'secret', admin: true}	Params received with extra 'admin' key
2	Authenticate user before action	User not logged in	Redirect to login page (authentication required)
3	User logs in successfully	Valid credentials	User session created
4	Retry POST /users with params	{email: '[e-mail]', password: 'secret', admin: true}	Params received again
5	Call user_params to permit params	params.require(:user).permit(:email, :password)	Filtered params: {email: '[e-mail]', password: 'secret'} (admin removed)
6	Create new User with filtered params	User.new(filtered params)	User object created without admin attribute
7	Save user to database	User object valid	User saved successfully
8	Redirect to root_path	User saved	User redirected to homepage
9	If save failed	Validation errors	Render new user form with errors
10	End	Process complete	Secure user creation finished

💡 Process stops after successful user creation or validation failure handled

Variable Tracker

Variable	Start	After Step 5	After Step 6	After Step 7	Final
params	{email: '[e-mail]', password: 'secret', admin: true}	{email: '[e-mail]', password: 'secret'}	User object with email and password	User saved in DB	User creation complete
user	nil	nil	User instance created	User instance saved	User instance persisted

Key Moments - 3 Insights

Why is the 'admin' parameter not saved even though it was sent in the request?

Because in step 5, user_params uses 'permit' to allow only :email and :password. The 'admin' key is filtered out, preventing unauthorized attribute assignment.

What happens if a user tries to create an account without being logged in?

At step 2, the 'authenticate_user!' before_action redirects them to the login page, stopping the create action until authentication succeeds.

How does the controller handle invalid user data?

If saving the user fails at step 9 due to validation errors, the controller renders the 'new' form again with error messages, allowing the user to correct input.

Visual Quiz - 3 Questions

Look at the execution table, what does the 'params' variable contain after step 5?

A {admin: true}

B {email: '[e-mail]', password: 'secret', admin: true}

C {email: '[e-mail]', password: 'secret'}

D Empty hash {}

💡 Hint

Check the 'Action' and 'Result/Output' columns at step 5 in the execution table.

At which step does the user get redirected to the login page if not authenticated?

A Step 1

B Step 2

C Step 4

D Step 8

💡 Hint

Look for 'Redirect to login page' in the 'Result/Output' column.

If the 'admin' parameter was permitted in user_params, what would change in the execution table?

A Step 5 would show 'admin' included in filtered params

B Step 2 would redirect to login page

C Step 7 would fail saving user

D No change at all

💡 Hint

Focus on the filtering of parameters at step 5.

Concept Snapshot

Rails Security Best Practices:
- Use 'before_action :authenticate_user!' to require login
- Use strong parameters with 'permit' to whitelist inputs
- Never trust user input; always validate and sanitize
- Handle authorization to restrict actions
- Encrypt sensitive data like passwords
- Log security events and handle errors gracefully

Full Transcript

This visual execution shows how Rails secures user creation. First, the app receives user input including email, password, and an extra admin flag. It requires users to be logged in before creating new users. If not logged in, it redirects to login. After login, it filters parameters to allow only email and password, removing admin to prevent unauthorized access. Then it creates and saves the user. If saving fails, it shows errors. This step-by-step flow helps beginners see how Rails protects apps from common security risks by validating, authenticating, and sanitizing inputs.

Practice

1. Which Rails feature helps prevent unwanted or dangerous user input from being saved to the database?

easy

A. Strong Parameters

B. Active Record Callbacks

C. Action Mailer

D. Asset Pipeline

Solution

1. Step 1: Understand user input control

   Strong Parameters allow you to specify which attributes are allowed from user input, preventing mass assignment vulnerabilities.

2. Step 2: Identify the correct Rails feature

   Active Record Callbacks and others do not control input filtering; only Strong Parameters do.

3. Final Answer:

   Strong Parameters -> Option A

4. Quick Check:

   User input filtering = Strong Parameters [OK]

Hint: Strong Parameters filter user input safely [OK]

Common Mistakes:

• Confusing callbacks with input filtering
• Thinking Asset Pipeline handles security
• Assuming Action Mailer controls input

2. Which line correctly enables CSRF protection in a Rails controller?

easy

A. enable_csrf_protection!

B. protect_from_forgery with: :exception

C. csrf_protect true

D. use_csrf_protection = true

Solution

1. Step 1: Recall Rails CSRF protection syntax

   The correct method to enable CSRF protection is protect_from_forgery with: :exception in controllers.

2. Step 2: Check other options for validity

   Other options are not valid Rails syntax and will cause errors or have no effect.

3. Final Answer:

   protect_from_forgery with: :exception -> Option B

4. Quick Check:

   CSRF protection syntax = protect_from_forgery [OK]

Hint: Use protect_from_forgery with: :exception [OK]

Common Mistakes:

• Using non-existent methods for CSRF
• Forgetting to add CSRF protection
• Misnaming the method or options

3. Given this Rails view code:

<%= raw @user.name %>

What security risk exists if @user.name contains HTML tags?

medium

A. Cross-Site Scripting (XSS) attack

B. SQL Injection

C. Mass Assignment

D. Denial of Service

Solution

1. Step 1: Understand output escaping in Rails views

   Using <%= %> escapes HTML by default, but if raw HTML is inserted, it can cause XSS.

2. Step 2: Identify the risk of unescaped HTML in user input

   If @user.name contains HTML tags and is not escaped, it can run malicious scripts in the browser, causing XSS.

3. Final Answer:

   Cross-Site Scripting (XSS) attack -> Option A

4. Quick Check:

   Unescaped HTML in views = XSS risk [OK]

Hint: Unescaped user input risks XSS attacks [OK]

Common Mistakes:

• Confusing XSS with SQL Injection
• Assuming Rails never escapes output
• Ignoring HTML tags in user input

4. You see this code in a Rails controller:

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

But users report they can update admin-only fields. What is the likely problem?

medium

A. CSRF protection is disabled

B. The controller action is missing

C. Strong Parameters are not used correctly

D. The database schema is incorrect

Solution

1. Step 1: Analyze the use of Strong Parameters

   The code shows permitted params, but if the controller does not use this filtered params hash for updating, mass assignment can happen.

2. Step 2: Identify why admin-only fields update

   If the controller uses unfiltered params or merges extra params, Strong Parameters are bypassed, causing security issues.

3. Final Answer:

   Strong Parameters are not used correctly -> Option C

4. Quick Check:

   Mass assignment issue = incorrect Strong Parameters use [OK]

Hint: Always use filtered params for updates [OK]

Common Mistakes:

• Assuming CSRF causes mass assignment
• Ignoring how params are passed to update
• Blaming database instead of controller code

5. You want to ensure all Rails app traffic is secure and user data is protected. Which combination of practices is best?

hard

A. Only use HTTPS and ignore CSRF and output escaping

B. Disable CSRF protection, use HTTP, and sanitize database inputs

C. Use HTTP, skip escaping output, and rely on user validation

D. Force HTTPS, enable CSRF protection, and escape all output

Solution

1. Step 1: Identify key security practices for web apps

   Forcing HTTPS encrypts data in transit, CSRF protection stops fake requests, and escaping output prevents XSS.

2. Step 2: Evaluate each option's security coverage

   Force HTTPS, enable CSRF protection, and escape all output covers all three essential protections. Others disable or ignore important protections, increasing risk.

3. Final Answer:

   Force HTTPS, enable CSRF protection, and escape all output -> Option D

4. Quick Check:

   HTTPS + CSRF + escaping = best security [OK]

Hint: Combine HTTPS, CSRF, and escaping for strong security [OK]

Common Mistakes:

• Ignoring CSRF protection importance
• Thinking HTTPS alone is enough
• Skipping output escaping