Comment by eranation | Hacker News Reader

Comment by eranation | Hacker News Reader

I'm a bit terrified that no one had security as their first item on the list. Many answers here are great and contain a lot of important concepts, frameworks and tools. But all of these are meaningless unless you have a strong spider sense for security. Not just the OWASP top 10, or top 100. But also criticizing your own business logic, not leaking information to the client side, not pushing things to git that should not be pushed. How to securely store passwords in the database. How to handle DDOS. How to prepare for the worst case, limit blast radius, all this while not hurting your productivity, as well as the end user's.

In the official sense, Security also includes availability (see the CIA triad), so a large portion of the bullets others have mentioned focuses on that.

I think a security mindset (including availability, which leads to thinking about disaster recovery, performance, redundancy, high availability, distributed systems as a mechanism to achieve it etc) is the first aspect that I look in a backend developer.

Other things are important, but security mindset in my opinion is the first layer in the foundation.

Others on my list that may be helpful to deep dive into:

1. HTTP, REST, know it well.

2. GraphQL as a complement/alternative to REST.

3. If using relational databases, learn what is a N+1 selects issue and how to solve it

4. If using NoSQL databases, learn about the CAP theorem and understand the tradeoffs etc

5. Learn to avoid premature optimization. Measure and profile before jumping to conclusion on theoretic bottlenecks that don't exist.

6. Unit test all the things, learn how to mock and what to mock, learn the difference between unit and integration tests.

7. Invest time in good design, read some other open source projets, see how they organize the code, what packages, what modules. Learn about dependency injection, Inversion of control.

8. Learn some cloud patterns, such as exponential backoff, throttling

9. Know everything about cookies, localStorage, XSS, CSRF, JWTs, and session cookies, stateless vs stateful architecture etc.

10. DevOps: Look into containers and serverless, CI/CD

11. Multithreading if you are in a language that has them.

Security is absolutely important. You’re right that most programmers don’t consider it and even my CS degree programming never emphasized security. However, I did a cybersec emphasis so I always consider the security implications of a system at the design stage. It’s significantly easier to build a secure system than it is to retrofit an insecure one.

One of the most important concepts is the principle of least privilege which is rarely ever discussed. Every tutorial I’ve seen, even paid ones, (this isn’t to say all of them) give their app master DB credentials. You could vastly improve your applications security just by leveraging your DB engine’s native access control.

For those using Postgres here’s a great resource for setting up RBAC: https://www.postgresql.org/docs/9.0/user-manag.html

How much of the typical application server authorization logic can we put into the database? Is it possible to setup authorization on a cell-level? Example: All users may change their own passwords, but only team admins may change the passwords of other users in their team.

I have never attempted this particular use case but, as far as I can tell this isn’t possible. While it is possible to grant privileges to change another user’s password, you would have to either make the team admin a super user (this grant all possible privileges) or by granting the Create Role privilege (which would allow them to create a new role with privileges they aren’t intended to have and switch to that role) so neither of these options are really any good.

A clarification on my previous comment: The way I’ve used Postgres RBAC is to create roles for each service in my application that needs DB access. For example say you have a service (in my case typically a lambda function) that only ever reads data from the DB and only from specific tables. I would create a role that only grants SELECT privileges for those specific tables. This also disallows UPDATE, DELETE, ALTER etc. privileges. Then assign this service that role. This mitigates the possible damage done if that service is compromised and shrinks your applications attack surface.

Spot on. Security should be baked into the way you work. It should be baked into an formal CS education too. I have joined teams full of seniors and "leads" who on paper should be miles ahead of me in terms of experience and competence and have had to teach them the basics you mentioned. It immediately creates a stressful overhead of constant auditing, nagging and unnecessary stress in the team when security is introduced after the fact.

Yep. I've worked in on a multi-tenant product in which I've seen senior engineers write APIs that would have allowed one tenant (enterprise customer) to access the data of another tenant!! Insane.

My perspective, having sold a company: security isn’t that important until you’re big. When you’re small you’re a small target, your resources are better spent on features and sales, and if you get hacked you can change your name and pretend you’re a new entity. I know this isn’t the ethical answer but it is the realpolitik answer. Invested maybe 50 dev-hours in security over 4 years.

Most devs are terrible when it comes to security. At the same time I'm glad they are because without them I'd be unemployed today.

Reply on news.ycombinator.com