Security scanning

Catching security holes before they ship

Rate limiting and pagination guard against abuse from the OUTSIDE. brakeman guards against mistakes from the INSIDE — it's a static analyzer that reads your Rails source (no running app, no database, no network calls) and flags patterns known to cause real vulnerabilities: SQL injection (building a query with raw string interpolation instead of a bound parameter), mass assignment (blindly trusting every field a client sends), unsafe redirects (redirecting to a URL a client controls), and more. Running it is a normal part of shipping — add it to the Gemfile, run it locally before a release, and wire it into CI so a vulnerable pattern can't merge unnoticed.

You've actually been practicing brakeman's favorite fix since module 8: strong parameters. params.permit(:walker_id, :dog_id) is Rails' guard against mass assignment — without it, a client could stuff EXTRA fields into a request body (status: "completed", price_cents: 1) and have them silently written to the record, because params is really just whatever JSON the client felt like sending. .permit is an explicit allowlist: only the fields you name make it through, everything else is dropped before it ever reaches .build or .update.

One more line worth knowing: secure headers (like X-Content-Type-Options: nosniff or a Content-Security-Policy) tell the BROWSER how to treat your responses defensively — Rails 8's config.action_dispatch.default_headers sets sane ones out of the box for an HTML app. An api_only JSON app like PawWalk's has less browser surface to defend, but it's the same category of "catch the mistake before it matters" thinking that brakeman and strong params both live in.