Rails Security Checklist
This checklist is limited to Rails security precautions and there are many other aspects of running a Rails app that need to be secured (e.g. up-to-date operating system and other software) that this does not cover. Consult a security expert.
One aim for this document is to turn it into a community resource much like the Ruby Style Guide.
BEWARE this checklist is not comprehensive and was originally drafted by a Rails developer with an interest in security - not a security expert - so it may have some problems - you have been warned!
The Checklist (in no particular order)
- Enable secure default callbacks for
ApplicationController(and other abstract controllers)
- Enforce authentication callbacks on actions (Devise's
- Enforce authorization callbacks on actions (Pundit's
- Enforce authorization-related scoping callbacks on actions (Pundit's
- Enforce CSRF protections (protect from forgery)
- Enforce authentication callbacks on actions (Devise's
- When disabling security-related controller callbacks, target actions on a case-by-case basis. Be very selective and deliberate and only disable it in that concrete controller. Avoid sweeping changes in the controller class hierarchy that would make subclasses less secure by default.
- Perform authentication and authorization checks in
routes.rb. It is intentional this duplicates many of the security checks you already perform in the controller callbacks (Devise's
authenticated) (motivations: defence-in-depth, swiss cheese model).
- Check all URL endpoints of engines and other Rack apps mounted in
routes.rbare protected with correct authentication and authorization checks. For sensitive engines/Rack apps favor not leaking they are installed at all by responding with 404 to non-logged in admin users.
- Check any developer/test-related engines/Rack apps do not expose any URL endpoints in production. They should not even leak (e.g. via 500 HTTP response code) information that they are installed. Ideally don't have their gems installed in production.
- Avoid HTML comments in view templates as these are viewable to clients. Use server-side comments instead:
# bad - HTML comments will be visible to users who "View Source": <!-- This will be sent to clients --> <!-- <%= link_to "Admin Site", "https://admin.example.org/login" %> --> # good - ERB comments are removed by the server, and so not viewable to clients: <%# This will _not_ be sent to clients %> <%#= link_to "Admin Site", "https://admin.example.org/login" %>
URL Secret Tokens
Refererheader leaking URL secret tokens to 3rd parties (e.g. password reset URLs can be leaked to CDNs, JS hosted by third parties, other sites you link to). (https://robots.thoughtbot.com/is-your-site-leaking-password-reset-links)
Random Token Generation
- CONTRIBUTOR NEEDED Use
SecureRandomor should we favor https://github.com/cryptosphere/sysrandom ?
- Avoid Rails insecure default where it operates a blocklist and logs most request parameters. A safelist would be preferable. Set up the
filter_parametersconfig to log no request parameters:
# File: config/initializers/filter_parameter_logging.rb Rails.application.config.filter_parameters += [:password] if Rails.env.production? MATCH_ALL_PARAMS_PATTERN = /.+/ Rails.application.config.filter_parameters += [MATCH_ALL_PARAMS_PATTERN] end
- Regularly audit what data is captured by log files, 3rd party logging, error catching and monitoring services. You (and your users!) may be surprised at what sensitive information you find. Data stored in log files and 3rd party services can be exploited.
- Favor minimal logging.
- Consider not archiving logs or regularly purging archived logs stored by you and 3rd parties.
- Filter and validate all user input
- Avoid code that reads from filesystem using user-submitted file names and paths. Use a strict safelist of permitted file names and paths if this cannot be avoided.
- Any routes that redirect to a URL provided in a query string or POST param should operate a safelist of acceptable redirect URLs and/or limit to only redirecting to paths within the app's URL. Do not redirect to any given URL.
- Consider adding a defensive layer to strong parameters to reject values that do not meet type requirements (https://github.com/zendesk/stronger_parameters)
- Consider sanitizing all ActiveRecord attributes (favoring the secure default of an opt-out sanitizer such as
Uploads and File Processing
- Avoid allow users to upload files to your (application) servers.
- Favor scanning uploaded files for viruses/malware using a 3rd party service. don't do this on your own servers.
- Operate a safelist of allowed file uploads
- Avoid running imagemagick and other image processing software on your own infrastructure.
- Throttle the amount of emails that can be sent to a single user (e.g. some apps allow multiple password reset emails to be sent without restriction to the same user)
- Avoid user-provided data being sent in emails that could be used in an attack. E.g. URLs will become links in most email clients, so if an attacker enters a URL (even into a field that is not intended to be a URL) and your app sends this to another user, that user/victim may click on the attacker-provided URL.
- Email security (needs more info)
- Use DKIM (https://scotthelme.co.uk/email-security-dkim/)
- Notify users via email when their passwords change | HOWTOs: Devise
- Favor sending notifications to user for significant account-related events (e.g. password change, credit card change, customer/technical support phone call made, new payment charge, new email or other contact information added, wrong password entered, 2FA disabled/enabled, other settings changes, login from a never-before used region and/or IP address)
- Do not send the new password via unencrypted email.
- Consider keeping an audit trail of all significant account-related events (e.g. logins, password changes, etc.) that the user can review (and consider sending this as a monthly summary to them)
- Use this audit trail or counters to rate-limit dangerous actions. For instance, prevent brute force password attacks by only allowing some maximum number of logins per second. You can also rate-limit the creation of particular database objects, globally or per-user, to prevent other kinds of DDOS or overflow attacks.
- Favor multi-factor authentication
- Favor Yubikey or similar
- Nudge users towards using multi-factor authentication (provide incentives and/or enable-as-default)
- Favor limiting access per IP-address, per device, especially for administrators
- Require user confirms account (see Devise's confirmable module)
- Lock account after X failed password attempts (see Devise's lockable module)
- Timeout logins (see Devise's timeoutable module)
- Favor mitigating user enumeration (see paranoid mode in Devise and https://www.owasp.org/index.php/Testing_for_user_enumeration_(OWASP-AT-002))
- Favor stronger password hashing with higher workload (e.g. favor more stretches). At time of implementation, research what the currently recommended password hashing algorithms are.
- Add calendar reminder to regularly review your current password storage practices and whether to migrate to a different mechanism and/or increase the workload as CPU performance increases over time.
- Prevent password reuse
- Enforce strong, long passwords
- Prevent commonly-used passwords (see Discourse codebase for an example)
- Proactively notify/prevent/reset users reusing passwords they've had compromised on other services (https://krebsonsecurity.com/2016/06/password-re-user-get-to-get-busy/ - interestingly Netflix apparently uses Scumblr, an open-sourced Rails app, to help with this: http://techblog.netflix.com/2014/08/announcing-scumblr-and-sketchy-search.html)
- Consider adding a layer of encryption to the stored password hashes (and other hashed secrets) (https://blogs.dropbox.com/tech/2016/09/how-dropbox-securely-stores-your-passwords/)
- Favor padding/increasing the time it takes to initially login and to report failed password attempts so as to mitigate timing attacks you may be unaware of and to mitigate brute force and user enumeration attempts. See how PayPal shows the "loading..." screen for a good few seconds when you first login (should this always be a fixed set amount of time e.g. 5 seconds and error asking user to try again if it takes longer?)(please correct me on this or add detail as this is an assumption I'm making about the reasons why PayPal do this).
- Mitigate timing attacks and length leaks on password and other secret checking code https://thisdata.com/blog/timing-attacks-against-string-comparison/
- Avoid using secret tokens for account lookup (includes API token, password reset token, etc.). Do not query the database using the token, this is vulnerable to timing attacks that can reveal the secret to an attacker. Use an alternative identifier that is not the token for the query (e.g. username, email,
# bad - timing attack can reveal actual token user = User.find_by(token: submitted_token) authenticated = !user.nil? # ok # step 1: find user by an identifier that is *not* the API key, e.g. username, email, api_locator user = User.find_by(username: submitted_username) # step 2: compare tokens taking care to mitigate timing attacks and length leaks. # (NB. favor *not* storing the token in plain text) authenticated = ActiveSupport::SecurityUtils.secure_compare( # using digests mitigates length leaks ::Digest::SHA256.hexdigest(user.token), ::Digest::SHA256.hexdigest(submitted_token) )
- Beware any hand-written SQL snippets in the app and review for SQL injection vulnerabilities. Ensure SQL is appropriately sanitized using the ActiveRecord provided methods (e.g. see
- Web application firewall that can detect, prevent, and alert on known SQL injection attempts.
- Keep Web application firewall rules up-to-date
- Minimize database privileges/access on user-serving database connections. Consider user accounts, database system OS user account, isolating data by views: https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet#Additional_Defenses
- Minimize the data you store on users (especially PII) and regularly review if you can store less or delete older data. E.g. Does the app need to store a user's birthday in perpetuity (or at all) or only need it at registration to check they're old enough? Once data is no longer needed favor deleting it.
- Remove database links between user profiles and their data if possible: http://andre.arko.net/2014/09/20/how-to-safely-store-user-data/
- Favor storing data encrypted (https://github.com/rocketjob/symmetric-encryption)
- Do not store API keys, tokens, secret questions/answers and other secrets in plain text. Protect via hashing and/or encryption.
- Encrypted, frequent database backups that are regularly tested can be restored. Consider keeping offline backups.
- Minimize production dependencies in Gemfile. Move all non-essential production gems into their own groups (usually test and development groups)
- Run Bundler Audit regularly (and/or Snyk/Gemnasium services)
- Update Bundler Audit vulnerability database regularly
bundle outdatedresults regularly and act as needed
- Join, act on, and read code for alerts sent by Rails Security mailing list
- Brakeman (preferably Brakeman Pro) runs and results are reviewed regularly
- Update Brakeman regularly
- Security scanning service (e.g. Detectify)
- Provide ways for security researchers to work with you and report vulnerabilities responsibly
- Update to always be on maintained versions of Rails. Many older Rails versions no longer receive security updates.
- Keep Ruby version up-to-date
Test Coverage for Security Concerns
- Test coverage ("AbUser stories") for security-related code. Including but not limited to:
- Account locking after X password attempt failures
- Password change notifications sent
- URL tampering (e.g. changing id values in the URL)
- Attackers, including logged-in users, are blocked from priveleged actions and requests. For example, assume a logged-in user who is also an attacker does not need a "Delete" button to submit an HTTP request that would do the same. Attacker-crafted HTTP requests can be mimicked in request specs.
Cross Site Scripting
- Regularly grep codebase for
raw, etc. usage and review
- Prevent team members from storing production data and secrets on their machines
- Enable hard disk encryption on team members hardware
Public, non-production Environments (Staging, Demo, etc.)
- Secure staging and test environments.
- Should not leak data. Favor not using real data in these environments. Favor scrubbing data imported from production.
- Avoid reusing secrets that are used in the production environment.
- Favor limiting access to staging/test environments to certain IPs and/or other extra protections (e.g. HTTP basic credentials).
- Prevent attackers making a genuine purchase on your staging site using well-known test payment methods (e.g. Stripe test credit card numbers)
- Favor using
\zas regular expression anchors instead of
- Favor changing secrets when team members leave.
- Do not commit secrets to version control. Preventative measure: https://github.com/awslabs/git-secrets
- Purge version control history of any previously committed secrets.
- Consider changing any secrets that were previously committed to version control.
- Secure cookie flags
- Restrict cookie access as much as possible
- Secure Headers (see gem)
- Content Security Policy
- Subresource Integrity for your assets and possibly 3rd party assets https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity
- Force TLS/SSL on all URLs, including assets, images. No mixed protocols.
- Use SSL labs to check grade
- Rack Attack to limit requests and other security concerns
- Consider DDOS protections e.g. via CloudFlare
- Have rake task or similar ready to go for mass-password reset that will notify users of issue.
- Consider having multiple ways of contacting user (e.g. multiple emails) and sending important notifications through all of those channels.
- Add reminders in developer calendars to do the regular security tasks (e.g. those elsewhere in this checklist) and for checking if this checklist has changed recently.
- Review and act on OWASPs literature on Ruby on Rails https://www.owasp.org/index.php/Ruby_on_Rails_Cheatsheet
- More covered at http://guides.rubyonrails.org/security.html
- See http://cto-security-checklist.sqreen.io/
- Security concerns trump developer convenience. If having a secure-defaults
ApplicationControllerfeels like a pain in the neck when writing a public-facing controller that requires no authentication and no authorization checks, you're doing something right.
- Security is a moving target and is never done.
- The DRY principle is sometimes better ignored in security-related code when it prevents defence-in-depth, e.g. having authentication checks in
routes.rband controller callbacks is a form of duplication but provides better defence.