Securing Your Rails App
summary
Claims that security is hard and pervasive get narrowed to concrete steps: inventory risks, environment, perimeter; log append‑only key transactions and alert on business anomalies; run static analysis like Brinkman, use bundler outdated and bundler audit to catch gem issues, subscribe to the Rails security guide, and keep Rails and gems current. Recommendations include whitelist over blacklist, sanitize with battle‑tested libraries, treat external input as data not code, add regression tests for fixes, and have an external code review or incident plan.
AI-written summary · about
chapters (41)
- 0:00Introduction
- 0:47Background
- 1:39Security
- 3:07Security is hard
- 4:14Security is really hard
- 4:48Awareness
- 5:17Risks
- 6:10Environment
- 8:17Time Strategy
- 9:07Visibility
- 9:48Vlogging
- 11:41Learning
- 12:54Plan
- 14:24Include Security
- 15:31How long will it take
- 16:07The fundamental security problem
- 17:03We cannot trust user input
- 18:17Blacklisting
- 19:21Blacklisting is not foolproof
- 22:06waitlisting
- 23:27sanitization
- 24:51dont go your own
- 25:17safe data handling
- 26:49Semantic check
- 28:33Recommendations
- 29:29Third Review Interview
- 30:56Brakeman
- 31:29Lean on the community
- 32:16Dont roll
- 33:10Devices
- 33:41Bruce Schneier
- 34:06Use Rails
- 35:00Optimize Rails
- 35:15Keep Rails up to date
- 36:21Rails Security List
- 36:41Rails Gems
- 37:14Unbundle Mountain
- 38:17Learn Bit
- 38:52Use Metrics
- 39:26Regression
- 40:36Wrap Up
related talks
36mNo Such Thing as a Secure Application
31mRails Application Security in Practice
38m"Application Security for Rails Engineers"
43mUncertain Times: Securing Rails Apps and User Data
43mSecuring Your Site
36mSecurity is hard, but we can't go shopping
20mDefending Against Data Breaches, as a Practicing Ruby Developer
40mSecurity Is Hard, But We Can't Go Shopping