guest@websec: ~/websec/01-introduction — zsh — 100×40 by SaKKo ENTH code:

guest@websec ~ % man 01-introduction

01 · Introduction

Rails gives us safe defaults. But no framework can make an app secure on its own.

The framework catches the mistakes it can predict. Everything else is on us, for as long as the app is live.

Why "secure framework" isn't enough

Modern frameworks escape HTML, add CSRF tokens and parameterize queries for you. That kills whole classes of bugs. It still isn't enough, for three reasons:

  1. People. One raw SQL string or one admin route without a check undoes everything. Rails can't guess which pages should be private.
  2. The whole stack. Server, database, proxy, CI, cloud account. If someone can read your .env, nice templates won't save you.
  3. Time. New attacks and new CVEs show up every month. Security is maintenance, not a one-off.
Rails starts us off well: escaped views, CSRF tokens, safe queries, encrypted cookies, strong params, security headers. New apps also get Brakeman in CI. Add bundler-audit for gem CVEs.
protected by defaultpartial: Rails helps, you must configure or finish ityour job: Rails does nothing here

Where attacks actually land

Most real breaches don't crack encryption. They walk through ordinary bugs: a missing permission check, an unvalidated field, a cookie sent over HTTP.

sim: the weakest linkdrag the sliders

Attackers take the easiest way in. You're only as strong as your weakest layer.

average strength:|what the attacker sees (minimum):

What the rest of this guide covers

The lessons come in five parts, ordered for a team that's new to security: injection first (02–04, starting with SQL injection, which has hit us before), then accounts and access control (05–09), the browser side (10–12), the server and its secrets (13–17), and operations (18–22). The quizzes are at the end. Go through them in order: later lessons build on earlier ones.

◀ Web Security Field Guide02 SQL Injection ▶