Goal

You’ll understand the core security protections Rails provides by default, and specifically what CSRF protection actually defends against, since understanding the threat makes the protection genuinely meaningful rather than just boilerplate.

Learn

Rails includes several security protections enabled by default, each addressing a genuine, real-world attack:

CSRF (Cross-Site Request Forgery) protection — Rails automatically includes a hidden authenticity token in every form. This defends against a genuine attack where a malicious site tricks a logged-in user’s browser into submitting a request to your application (like a hidden form auto-submitting to transfer funds) — since the malicious site can’t know or forge the correct authenticity token, Rails rejects the forged request. This connects directly to the strong parameters lesson from Part 3.2 — both exist specifically to prevent a request from doing something the application didn’t genuinely intend to allow.

SQL injection protection — ActiveRecord automatically parameterizes queries built through its normal methods (where, find_by, etc.), preventing malicious input from being interpreted as executable SQL:

# Safe - ActiveRecord automatically parameterizes this
Product.where("name = ?", user_input)

# DANGEROUS - directly interpolating user input into raw SQL
Product.where("name = '#{user_input}'")

The second pattern is genuinely dangerous specifically because it directly interpolates unescaped user input into a raw SQL string, potentially letting a malicious user inject their own SQL commands. The first pattern, using a placeholder (?) with a separate argument, lets ActiveRecord safely escape the input automatically, regardless of what it actually contains.

Mass assignment protection, covered in Part 3.2’s strong parameters, is the third major default protection — together, these three specifically address genuinely common, well-known real-world web application vulnerabilities, not obscure edge cases.

Decision Task

A developer writes Product.where("name = '#{params[:search]}'") to implement a search feature. Before reading on: what specific real vulnerability does this create, and what’s the safe alternative?

Show Answer

This creates a genuine SQL injection vulnerability — directly interpolating unescaped user input into a raw SQL string lets a malicious user craft input that gets interpreted as executable SQL commands, rather than just a plain search term. The safe alternative is Product.where("name = ?", params[:search]), using a placeholder with a separate argument, letting ActiveRecord safely escape the input automatically regardless of its actual content.

Common Mistake

Directly interpolating user input into a raw SQL string (using Ruby string interpolation like #{}) instead of using ActiveRecord’s parameterized query methods. This is exactly the SQL injection vulnerability pattern this lesson covers — the fix isn’t complicated, it’s specifically using placeholders (?) with separate arguments rather than building the SQL string with interpolated user input directly.

Practice Questions

1. What real attack does CSRF protection specifically defend against?

Show Answer

A malicious site tricking a logged-in user’s browser into submitting an unintended request to your application, like a hidden auto-submitting form.

2. Rewrite this dangerous query safely: Order.where(“status = ‘#{params[:status]}'”)

Show Answer

Order.where("status = ?", params[:status])

3. Why does Product.where(“name = ?”, user_input) genuinely protect against SQL injection, unlike direct string interpolation?

Show Answer

ActiveRecord automatically and safely escapes the input provided as a separate argument, regardless of what it actually contains, rather than treating it as a literal part of the raw SQL string being constructed.

4. True or False: Rails’ three major default security protections (CSRF, SQL injection prevention, mass assignment protection) address obscure, rarely-relevant edge cases.

Show Answer

False — these specifically address genuinely common, well-known, real-world web application vulnerabilities that affect applications regularly, not obscure edge cases.

5. How does CSRF protection connect conceptually to strong parameters from Part 3.2?

Show Answer

Both exist specifically to prevent a request from doing something the application didn’t genuinely intend to allow — CSRF prevents forged requests from unintended sources, strong parameters prevent unintended fields from being mass-assigned.

Try It Yourself

Without looking back, identify what’s wrong with this query and rewrite it safely: User.where(“email = ‘#{params[:email]}'”)

Show Answer

This is vulnerable to SQL injection through direct string interpolation of unescaped user input. Safe version: User.where("email = ?", params[:email]) — using a placeholder with a separate argument, letting ActiveRecord safely escape the input automatically.

Quick Check

1. What does CSRF protection defend against?

Show Answer

A malicious site tricking a logged-in user’s browser into submitting an unintended request.

2. What does SQL injection protection prevent?

Show Answer

Malicious user input being interpreted as executable SQL commands.

3. What’s the safe pattern for including user input in an ActiveRecord query?

Show Answer

Using a placeholder (?) with the value as a separate argument, not direct string interpolation.

4. What’s the dangerous pattern to avoid?

Show Answer

Directly interpolating user input into a raw SQL string using Ruby string interpolation.

5. What third major default Rails security protection was covered in an earlier Part?

Show Answer

Mass assignment protection, via strong parameters (Part 3.2).