Skip to content

Application Security

Walter McGinnis edited this page Jan 29, 2014 · 3 revisions

Areas where more security is worth considering

It's becoming more common practice to require re-entering of a logged in user's password when the user tries to does a task that has security implications.

Example: Github requires password to be re-entered when a user wants to delete a repository.

I'm not sure we want to do this quite yet, but it is worth considering if the application becomes as popular as we hope.

In our application here are some tasks where we may want recheck the password of the user:

Normal Users
  • changing user password
  • changing user email
Verified Responders
  • answering a question
Staff Members
  • deleting a question
  • verifying a user as a responder

As I said, I don't think these need to be implemented now, but I wanted to raise them as something to consider long term.

Security Report 2014-01-29

Reread the Rails Security Guide.

We are in decent shape generally as we do no trust user input in most cases and therefore many vectors of attack are closed. If we ever decide to except submitted HTML in our questions, that may change, but it relatively known path to secure HTML input.

A JSON utility for identifying potential recipients or matching people in our data had a few areas needing hardening and improvement. These commits tightened things up:

Our current major area of insecurity is not forcing HTTPS use when logging in or signing up. Expect commits to change the situation in the next day or two.

Update on HTTPS: implemented in https://github.com/opengovernment/askthem/commit/bed7861aaa087f7663817ae31e5672016a7e39f8

I'm also hoping to run security audits on commits through something like CodeClimate.

Please add further Security Reports to this page as needed