Extremely Important!!!!
Never, under any circumstances should you put AWS keys into a file. Doing so introduces a major security risk and may expose them to the public. Do not put them in a file “just to test” or “just to try” to get around access denied warnings. If these keys are pushed to GitHub it is difficult to get them removed completely. These keys must only be entered as environmental variables locally and Heroku environments. See below or talk to your alumni mentor for how to use them safely. When in doubt, ask!!
Extremely Important Part 2!!!!
This is a learning experience that may use real data. It is MUCH more important that you are careful and understand fully what you are doing rather than get a feature done. I would much, much rather you fail (for the moment) to complete a feature you planned for the sprint than expose sensitive data, login credentials, or keys used to connect to services and APIs. Maintain perspective. None of these projects must be completed “on time”.
Personal Data Security
- You are welcome to make your individual project’s GitHub repo private. Just make sure that you add your instructor as a viewer for grading.
- Consider using a non-identifiable nom de plume as your user name whenever using a third-party service such as Heroku. I’m trusting you to submit links to your own work, and I don’t need to see your real name when I visit your site.
- When using third party services in this class, you may use a non-Grinnell email address.
- If you are commenting code, do not use real, full names or Grinnell email addresses if you are leaving a note for yourself or another team member. Adopt and use nick names or initials.
- When creating your individual project, do not list the courses you have taken or publish any information about your academic record.
- Your team should adopt a team name and might create a temporary email address that will be used for deploying and managing your team’s Heroku app during the course rather than using Grinnell emails for collaborators. (Share it with your instructor!)
Security with Ruby on Rails Projects
Edge Guides has a comprehensive guide to common web application vulnerabilities and the ways that Rails (5.2+) can be used to avoid them. Discuss this option with your alumni mentor.
Use Environmental Variables
Rather than use configuration files, you can set up environmental variables locally and in Heroku. See this brief overview on how to set up environmental variables in Heroku.
For development, using the dotenv gem might be your safest bet at this stage of each of your projects. Installation and usage are given in the environmental variables overview.
Upgrade to Rails 5.2+/6
Rails 5.2 has a way of storing credentials through an encrypted file. The discussion is part of a long (and very good) article on web app security.
Upgrading your current code to Rails 5.2 or Rails 6 would be ideal, except that you may encounter new issues whenever you change versions. When you start a new project, use Rails 6. If you are working with legacy code that is older than Rails 5.2, check with your alumni mentor.
The most important thing is to be aware of what information you have stored locally that is sensitive and should not be put up on a readily accessible repo .. unless it is encrypted.
Using a Sandbox
According to Ian, many services provide a sandbox (i.e. play or development) mode via a separate set of credentials. When testing, use sandbox credentials or fake credentials (talk to your mentor about how to handle these seams during testing).
Alternatively, some services will let you limit credentials to performing certain actions or “read only” mode. Or allow you to cap the amount of activity.
Using VCR for Testing
If you are using VCR and the app has sensitive credentials, you need to check with your mentor so that your credentials don’t leak into your test data.
Things NOT to commit to GitHub
Try to avoid uploading real data to a repo, even if encrypted. Other files might be uploadable, if they are properly secured. Talk to your mentor about the best strategy for your team.
- Real data – yours or that of your community partners. Make sure that live databases are ignored by GitHub (use .gitignore)
- Keys to APIs
- Login credentials
