Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> 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.

For example, I think this is excellent reading for any young company thinking about security: https://medium.com/starting-up-security/starting-up-security...



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.


This is usually addressed in your program policy. For example, look at https://hackerone.com/twitter :

> 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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: