3 ms·

Congrats on the launch. What's your approach to security? I notice there's no mention of any penetration testing, no security policy, no responsible disclosure

Congrats on the launch. What's your approach to security? I notice there's no mention of any penetration testing, no security policy, no responsible disclosure policy, no place to report security vulnerabilities. You're absolutely right (in other comments) that getting the UX and so on right for authn/authz is really hard, and there are a ton of edge cases, but I know from experience that there are a ton of security edge cases too. Things like rotating session tokens at the right time, how that interacts with password resets, HTTP referrers, etc, is all quite tricky to get right. I've built with battle-hardened, decades-old frameworks and still gotten a few details wrong. To delegate all of this responsibility to a third party product, even if it's open-source, rather than building it yourself, is to give up control. Sure you can edit the code, but can you find the bug in an unfamiliar codebase, effectively test in a testing environment your unfamiliar with, and create a valid build? That's a lot harder. If I were to delegate that responsibility to a product like this, I'd want to know that they've taken security at least as seriously as I do, ideally much more seriously because it's the core of their product. Right now I'm not convinced.

n2d4 2y ago
We added a security policy: https://github.com/stack-auth/stack/blob/dev/.github/SECURITY.md https://github.com/stack-auth/stack/blob/dev/.github/SECURIT... If it helps you, we delegate the most vulnerable parts of the application, such as OAuth, to lower-level frameworks — similar to the unmanaged auth libraries people use today. We are essentially a thick wrapper around those, to create a full-stack platform from primitives. (Of course, that doesn't mean the thick wrapper cannot be vulnerable, but it helps with some of the most hideous bugs.) The point I disagree with is that building it yourself is better than delegating it to a third-party — at best, you can secure your auth against vulnerabilities you're aware of. Unfortunately, this fallacy keeps coming up, but generally it's the case that homebrew auth is not more secure than open-source libraries, nor is proprietary code.
- danpalmer 2y ago
  Thanks for adding a security policy. To be clear I'm certainly not suggesting people write their own auth from scratch. My point is more that even when using mature frameworks it's possible to miss necessary bits or accidentally cause vulnerabilities around the edges. My experience here is building auth on Django's built in auth system which is fantastic. The issue comes when you start customising session management (for real product use-cases!), without then understanding all the interactions between various flows. As we were using a framework in our application, fixing these sorts of issues was straightforward, however if we had used a third-party hosted application (even if running on our own infra), it would likely have been far harder to spot the issues and address them.
  - n2d4 2y ago
    Understood. Thanks for clarifying :)

n2d4 2y ago

We added a security policy: https://github.com/stack-auth/stack/blob/dev/.github/SECURITY.md https://github.com/stack-auth/stack/blob/dev/.github/SECURIT... If it helps you, we delegate the most vulnerable parts of the application, such as OAuth, to lower-level frameworks — similar to the unmanaged auth libraries people use today. We are essentially a thick wrapper around those, to create a full-stack platform from primitives. (Of course, that doesn't mean the thick wrapper cannot be vulnerable, but it helps with some of the most hideous bugs.) The point I disagree with is that building it yourself is better than delegating it to a third-party — at best, you can secure your auth against vulnerabilities you're aware of. Unfortunately, this fallacy keeps coming up, but generally it's the case that homebrew auth is not more secure than open-source libraries, nor is proprietary code.

danpalmer 2y ago
Thanks for adding a security policy. To be clear I'm certainly not suggesting people write their own auth from scratch. My point is more that even when using mature frameworks it's possible to miss necessary bits or accidentally cause vulnerabilities around the edges. My experience here is building auth on Django's built in auth system which is fantastic. The issue comes when you start customising session management (for real product use-cases!), without then understanding all the interactions between various flows. As we were using a framework in our application, fixing these sorts of issues was straightforward, however if we had used a third-party hosted application (even if running on our own infra), it would likely have been far harder to spot the issues and address them.
- n2d4 2y ago
  Understood. Thanks for clarifying :)