Ruby on Rails Audit Complete

Original Article ↗ Hacker News Discussion ↗

Audit scope, timing, and funding

  • Commenters share the PDF report and note the audit is explicitly partial: the full Rails codebase is too large to cover, so tests focus on common vulnerability classes and future-focus areas.
  • Some vulnerabilities appear not yet fixed in Rails 8.0.2; people wonder if they’ll land in 8.1.
  • The audit was funded by a non‑profit; others asking for Django/Spring/Phoenix audits are told audits cost real money and depend on raising comparable funds.
  • The audit team joins the thread, saying they’d like to do more framework audits but are constrained by grant funding.

Security findings and framework defaults

  • Several see the low number of findings as a positive sign for a mature, widely-used framework.
  • Others emphasize this isn’t a full guarantee of safety, just added confidence that common issues are being looked at.
  • Discussion around SameSite cookie settings: “Strict” is more secure but breaks common flows (e.g., opening links from other sites not logged in), so trade-offs matter.
  • A finding about Rails generating params for GET/HEAD/DELETE is viewed as potentially dangerous in badly structured apps.
  • The recommendation to avoid raw SqlLiteral is debated: some argue Rails already has a good SQL model (Arel) but it’s under-documented; others stress that forcing explicit “unsafe” APIs and good defaults is crucial.

Rails productivity, scaling, and alternatives

  • Many reiterate that Rails remains extremely productive for CRUD/B2B apps, with batteries-included defaults (auth, mailers, file uploads, pagination, search, etc.).
  • The “Rails doesn’t scale” trope is strongly disputed; people cite large deployments and argue architecture mattered more than framework at places like Twitter.
  • Others prefer Elixir/Phoenix or Go for performance, type safety, concurrency, or operational reasons, but acknowledge Rails’s ecosystem, funding, and hiring pool as major advantages.
  • Some say equivalent productivity now exists in other ecosystems, while others maintain Rails is still uniquely cohesive.

Typing, tooling, and language experience

  • Static typing (or lack of it) is a recurring theme: some teams consider no static types a deal-breaker; others argue tests plus convention are enough.
  • Ruby’s RBS/Steep/Sorbet efforts are criticized as awkward compared to Python/TypeScript’s gradual typing; some think Ruby should avoid types entirely.
  • Proponents push back that everything in Ruby is typed at runtime and that tools and debuggers are sufficient when used correctly.

Elixir/Phoenix vs Rails

  • Several with experience in both stacks find Elixir more performant, safer (compile-time checks), and well-suited to realtime/distributed workloads via the BEAM.
  • Counterpoints:
    • Library and integration ecosystems are smaller; you often hit missing or abandoned libraries.
    • Hiring and training can be harder; teams used to OO or JS/Ruby sometimes struggle with functional patterns.
    • Phoenix lacks a Rails-level all-in-one story for some features (though LiveView, Ecto, and projects like Ash reduce that gap).
  • There’s debate about whether real-time, persistent connections justify Elixir’s trade-offs for most web apps.

Rails popularity and ecosystem shifts

  • Multiple factors are cited for Rails’s relative decline from its peak:
    • Node.js enabling JS end-to-end and bootcamps focusing on “one language.”
    • Python’s rise in data science/ML and academia.
    • Mobile + APIs splitting frontend/backends and pushing SPAs, microservices, and Go/Java ecosystems.
    • The allure of “new and simple” stacks vs a maturing, more complex Rails.
    • Modern concurrency stories (async/await) in other languages.
  • Some argue monoliths and Rails are being rediscovered as microservice complexity proves costly, even if search trends show a long-term decline.

AI tooling and language choice

  • One view: with generative AI, niche stacks are a liability because AI models are weaker on them; Rails is “good enough” and well-supported.
  • Others report mixed results: some find OpenAI models strong on Rails, while Anthropic models struggle; some prefer Go from an AI-assistance standpoint.

“Magic”, debugging, and large Rails codebases

  • Experiences diverge sharply:
    • Critics find large Rails apps (e.g., Gitlab) “magical” and hard to reason about: heavy metaprogramming, dynamic dispatch, and no static types make “find all references” difficult.
    • Defenders say this improves dramatically if you lean on Ruby’s debuggers and introspection (e.g., method source location, REPL loading) instead of static-language habits.
  • There’s disagreement over whether requiring runtime introspection just to trace calls is acceptable developer experience.

Frameworks, security, and JS “equivalents”

  • Several note that using established frameworks like Rails/Django/Laravel/Spring already mitigates many common security issues compared to ad hoc stacks.
  • In JS, candidates like SvelteKit, RedwoodJS, and Wasp are proposed as “Rails-like,” but critics argue they rarely provide equally opinionated, integrated DB/ORM and full-stack conventions.
  • Overall, commenters view the audit as a useful, if partial, reinforcement that Rails remains a viable and secure choice for many web applications.