I’m the CTO at Sqreen and I do love Matasano (cryptopals... awesome crypto challenge https://cryptopals.com/).
Realistically, security audits or bug bounty are not doable in seed startups - where most of the time no one has any security knowledge, and no money :)
Thanks for the missing things we will update! By the way this is open source, feel free to contribute: https://github.com/sqreen/CTOSecurityChecklist (not sure this is 100% today with the version on Sqreen.io, we’ll get there this week).
I have only one thing to nag about. Password complexity rules. Please only do length check and promote checking against dictionary passwords to be rejected. For password security this was last year hot document: https://www.nist.gov/itl/tig/projects/special-publication-80...
There could be a different between password rules for your users, and for your employees. The former should probably be more focused on usability, the latter on security.
> Realistically, security audits or bug bounty are not doable in seed startups - where most of the time no one has any security knowledge, and no money
Ehhhhhhh...I disagree.
1. Most of my clients tend closer to seed stage than to well-funded.
2. You don’t need security expertise or money to run a good bug bounty program. You can start one immediately. There are enough high quality resources available for free on the internet (that are not content marketing) that you can learn most of the important unknown unknowns.
What do you do when the response to a bug bounty is "yeah, we already knew about that, and we're not planning to fix it soon because the consequences aren't high"? In my experience that's a pretty common scenario for early to medium stage startups.
It's not just a common scenario for early to medium stage startups. It's also a common scenario for every other business with a bug bounty program.
Sometimes, the consequences aren't high.
"Your CORS is configured to allow access from another domain, also owned by you."
"You can give yourself a redirect to any site by intercepting and modifying your own Host header."
"Your static blog on a separate domain from your actual site is accessible over unencrypted HTTP."
"If I zoom in on your web page, the text becomes blurry."
If your question was from the other end, "what do you do as the company when you get a report like this?", I say something like "We don't believe that this warrants fixing at this time. Thanks for your interest in our program, and we hope you continue reporting to us in the future!"
What I'm thinking of are things like "a paying customer can DoS you with a carefully constructed malicious input". That usually won't be practical issue if you're small enough to know all your customers - but it has the potential to be very problematic if you incentivize people to find it.
> Accessing private information of other users, performing actions that may negatively affect Twitter users (e.g., spam, denial of service), or sending reports from automated tools without verifying them will immediately disqualify the report
