Secure Rails

Everyone writing code must be responsible for security. 🔒

Start with the Rails Security Guide to see how Rails protects you.

Also, check out this guide for securing sensitive data.

Best Practices

Secrets

Keep secret tokens out of your code - ENV variables are a good practice

Why: You don’t want your version control host, CI provider, or any other service with access to your code to have access to your secrets. If one of these services is compromised, or a single developer’s account on one of these services is compromised, you don’t want to lose your secrets.

SQL Injection

Even with ActiveRecord, SQL injection is still possible if misused
```
User.group(params[:column])
```
is vulnerable to injection. Learn about other methods

Why: This explains it well

Host Header Injection

Prevent host header injection - add the following to config/environments/production.rb
```
config.action_controller.default_url_options = {host: "www.yoursite.com"}
config.action_controller.asset_host = "www.yoursite.com"
```
Why: An attacker can pass a bad host header. If your app uses caching, this bad host may be cached and served to other users (this can happen with *_url helpers).

Data in Transit

Protect all data in transit with HTTPS - you can get free SSL certificates from Let’s Encrypt

Add the following to config/environments/production.rb
```
config.force_ssl = true
```
Why: So attackers can’t eavesdrop or modify pages
Add your domain to the HSTS Preload List
```
config.ssl_options = {hsts: {subdomains: true, preload: true, expires: 1.year}}
```
Why: If someone visits your website over HTTP, even if you have an HTTPS redirect, an attacker can perform a middleperson attack. sslstrip is a popular tool for this. The preload list ships with the browser and instructs it to always use HTTPS for specific domains.

Data at Rest

Protect sensitive database fields with application-level encryption - use Active Record Encryption or a library like Lockbox and possibly KMS Encrypted

Why: This protects sensitive data if the database or a database backup is compromised
Protect sensitive files with application-level encryption - use a library like Lockbox

Why: This protects sensitive data if file storage is compromised, or if someone accidentally makes an S3 bucket public
Make sure sensitive request parameters aren’t logged
```
Rails.application.config.filter_parameters += [:credit_card_number]
```
Use Logstop as an additional line of defense

Why: You don’t want sensitive data in your log files if they are compromised

Authentication

Use a trusted library like Devise for authentication (see Hardening Devise if applicable)

Why: Secure authentication is hard. Use a library that’s battle-tested. Don’t roll your own.
Notify users of password changes

Why: So users are aware if someone tries to hijack their account
Notify users of email address changes - send an email to the old address

Why: So users can’t silently hijack the account by changing the email, then the password
Rate limit login attempts by IP with Rack Attack

Why: To slow down credential stuffing attacks
Log all successful and failed login attempts and password reset attempts (check out Authtrail if you use Devise)

Why: So you have an audit trail when accounts are compromised. You can also use this information to detect compromised accounts.
Rails has a number of gems for authorization - we like Pundit

Why: To prevent users from accessing unauthorized data

Browser Caching

Set autocomplete="off" for sensitive form fields, like credit card number

Why: So other users of the browser can’t access this saved information

Ask the browser not to cache pages with sensitive information

response.headers["Cache-Control"] = "no-store, must-revalidate, private, max-age=0"
response.headers["Pragma"] = "no-cache"
response.headers["Expires"] = "Sat, 01 Jan 2000 00:00:00 GMT"

Why: So other users of the browser can’t click the back button and view sensitive information

Data Leakage

Ask search engines not to index pages with secret tokens in the URL
```
<meta name="robots" content="noindex, nofollow">
```
Why: So search engines don’t index (and therefore expose) the tokens

Cross-Site Scripting (XSS)

Use json_escape when passing variables to JavaScript, or better yet, a library like Gon
```
<script>
  var currentUser = <%= raw json_escape(current_user.to_json) %>;
</script>
```
Why: To prevent cross-site scripting (XSS)
Be careful with html_safe

Why: It bypasses escaping
Don’t use assets from a public CDN, as this creates unnecessary availability and security risk

Why: This adds another attack vector for an attacker

Open Source Tools

Brakeman is a great static analysis tool - it scans your code for vulnerabilities

bundler-audit checks for vulnerable versions of gems

gem install bundler-audit
bundle audit check --update

To fix Insecure Source URI issues with the github option, add to the top of your Gemfile:

git_source(:github) do |repo_name|
  repo_name = "#{repo_name}/#{repo_name}" unless repo_name.include?("/")
  "https://github.com/#{repo_name}.git"
end

And run bundle install.

npm audit checks for vulnerable versions of JavaScript packages (if you use package.json)

git-secrets prevents you from committing sensitive info

brew install git-secrets
git secrets --register-aws --global
git secrets --install
git secrets --scan

Mailing Lists

Subscribe to ruby-security-ann to get security announcements for Ruby, Rails, Rubygems, Bundler, and other Ruby ecosystem projects.

Services

Observatory scans your site for best practices
Code Climate provides a hosted version of static analysis
HackerOne allows you to enlist hackers to surface vulnerabilities

Additional Reading

Contributing

Have other good practices? Know of more great tools? Help make this guide better for everyone.

Also check out Production Rails.

ankane/secure_rails