Framework audits/Rails
Rails protects against most common web vulnerabilities by convention, so an audit looks for places the conventions were suspended. The findings that matter are permit-all strong parameters, string interpolation inside where clauses, CSRF verification skipped on controllers that accept writes, and credentials handled outside the encrypted store.
Because Rails secures by convention rather than configuration, its vulnerabilities tend to be single lines that opt out — one permit-all, one skip-forgery-protection — rather than settings left at a bad default.
These are patterns we look for in code produced this way — not flaws in Rails itself. Each names the check that finds it.
Strong parameters exist to whitelist what a request may set. A controller that permits all keys restores the mass-assignment vulnerability the feature was introduced to prevent, and it is a single expressive line that reads as convenience rather than as a security decision.
Detected by: Unvalidated request input
ActiveRecord parameterises when given a placeholder and an argument. Passing an interpolated string instead — which is shorter and works identically in testing — puts the request value directly into the SQL. This is the dominant source of injection in Rails codebases.
Detected by: SQL string concatenation
Forgery protection is enabled by default, and skipping it is a one-line change usually made to unblock an API client or a webhook. Where that controller also accepts state-changing requests from browser sessions, the skip removes protection from those too.
Detected by: Unvalidated request input
Rails provides an encrypted credentials file precisely so secrets can be committed safely. Values placed in plain initialisers or checked-in environment files instead are in history permanently, and inherited Rails applications frequently predate the encrypted store entirely.
Detected by: Hardcoded secret value
Every check named above runs automatically. Free on public repositories, no signup, results in under three minutes — with the file and line for each finding.
Largely yes. CSRF protection, parameterised queries, output escaping and strong parameters are all on by convention. Rails vulnerabilities are usually opt-outs — a single line that suspends a protection for a reason that made sense at the time and was never revisited.
Through string interpolation in query methods. ActiveRecord parameterises when given a placeholder and a separate argument, but interpolating the value into the string bypasses that entirely, and the two forms behave identically in testing.
In the encrypted credentials store, which exists so they can be committed safely, or in environment variables. Anything that has sat in a plain initialiser or a committed environment file should be treated as exposed and rotated, since removal does not clear git history.