Goal

You’ll practice debugging and reviewing existing Rails code, applying diagnostic thinking from across this entire course to spot problems in code you didn’t write yourself.

Learn

Reviewing Rails code is a genuinely different skill from writing new code — it requires actively checking for specific known problem patterns, not just reading code and assuming it’s correct because it superficially looks reasonable. A structured review checklist, pulling together this whole course:

• Association direction (Part 2.4): Is the foreign key on the correct (belongs_to) side?
• Strong parameters (Part 3.2): Is every create/update action using properly scoped, explicitly permitted parameters?
• Redirect vs. render (Part 3.4): Do successful create/update actions redirect, avoiding duplicate resubmission risk?
• SQL safety (Part 5.4): Are any raw queries using string interpolation instead of safe parameterized placeholders?
• Callback scope (Part 4.2): Do model callbacks handle genuinely data-related logic, or do they hide broad side effects that should be more visible?

This kind of review reveals that Rails code can run without crashing and still contain genuine, real problems invisible to a quick read-through — a SQL injection vulnerability, for example, often doesn’t surface until someone specifically tests with malicious input, not during normal, expected use.

Decision Task

You’re reviewing a controller’s update action and find Order.where("status = '#{params[:status]}'") being used to filter results. Before reading on: what specific vulnerability does this contain, and why might it pass casual code review despite the real risk?

Show Answer

This contains a genuine SQL injection vulnerability (Part 5.4) from directly interpolating unescaped user input into a raw SQL string. It might pass casual review because it looks like it “works” during normal testing with expected, well-behaved input — the vulnerability only becomes apparent when specifically tested with malicious input designed to exploit the interpolation, which normal functional testing typically doesn’t include.

Common Mistake

Reviewing Rails code purely by checking “does it work correctly for normal, expected input” rather than deliberately checking for the specific known problem patterns covered throughout this course. As this lesson demonstrates, code can function correctly for typical use while still containing a genuine security vulnerability or structural issue that only reveals itself under specific, less common conditions.

Practice Questions

1. A reviewed model has belongs_to :author on a Book model, but the authors table (not books) has the author_id column. What’s wrong, from Part 2.4?

Show Answer

The foreign key is on the wrong table — belongs_to :author on Book means the books table should have the author_id column, not the authors table; this association is set up backwards.

2. A reviewed create action does Comment.new(params[:comment]) directly, with no .permit call anywhere. What real risk does this represent, from Part 3.2?

Show Answer

A genuine mass assignment vulnerability — without strong parameters explicitly permitting specific fields, unexpected extra fields in the request could be assigned directly onto the model.

3. A reviewed create action directly renders a view on success, rather than redirecting. What real risk does this represent, from Part 3.4?

Show Answer

Duplicate form resubmission if the user refreshes the page, since a rendered response (rather than a redirect) would cause a refresh to resubmit the original form data again.

4. True or False: Rails code that works correctly during normal testing is sufficient evidence it’s free of genuine security vulnerabilities.

Show Answer

False — this is the core lesson here; some vulnerabilities (like SQL injection) only reveal themselves under specifically malicious input, not normal expected testing.

5. List the five review checklist categories from this lesson, in your own words.

Show Answer

Association direction correctness, strong parameters usage, redirect vs. render after data changes, safe SQL query construction, and appropriate scope of model callbacks.

Try It Yourself

Using this lesson’s checklist, review a piece of Rails code you’ve written earlier in this course (or elsewhere) and see if you can spot at least one place where the code could be made more robust or secure, even if it currently works correctly.

This is an open, ungraded reflection exercise — there is no single correct answer to reveal.

Quick Check

1. Why is reviewing Rails code a genuinely different skill from writing new code?

Show Answer

It requires actively checking for specific known problem patterns, not just reading code and assuming correctness from a casual glance.

2. What association-direction check does the review checklist include?

Show Answer

Whether the foreign key is on the correct (belongs_to) side of a relationship.

3. What strong-parameters check does the review checklist include?

Show Answer

Whether every create/update action uses properly scoped, explicitly permitted parameters.

4. Can Rails code work correctly during normal testing while still containing a genuine security vulnerability?

Show Answer

Yes — this is the core point of this lesson; some vulnerabilities only surface under specific, less common (often malicious) conditions.

5. What SQL-safety check does the review checklist include?

Show Answer

Whether any raw queries use unsafe string interpolation instead of safe parameterized placeholders.