Solopreneurs how do you ensure that your web app is secure?

I think @asimon has covered most points really well. In addition to that, here is what else we do to protect our SaaS:

• If using AWS, run everything inside a VPC so that you can control what resources are exposed to the public. Most cloud application providers let you have some sort of private network. All server to server comms (i.e. app server to database, or app server to background worker servers) should be done within the private network only. Database servers should also only be set up to accept incoming connections from the private network, or from your own IP address only in the firewall and connection rules.
• Set up CloudFlare or CloudFront as your content delivery network, and then set up firewall rules which will help auto block things like DDoS attacks, or bad actors running bots to explore common framework vulnerabilities.
• Use a service like EnvKey.com to manage your passwords and keys. This way, you can securely manage them as you grow and have other people working on your codebase. As external developers come and go, you can rotate passwords, but the best thing is that the end developer doesn't even see or know what those passwords ever were.
• Set up (and pay for) good monitoring tools to check application server logs and general availability. Something like New Relic or AppSignal or Sentry etc. that can immediately alert you if multiple errors happen in a short timeframe (likely hack attempt), and also Uptime Robot or BetterUptime to alert you if your site goes offline for whatever reason.
• Make your database server password something long and unrememberable, and remember that the inconvenience of looking it up every time you need access to that server is a small price to pay to prevent anyone else from second guessing it. (Tip: I use randomkeygen.com to generate long, complex passwords for all my servers).
• Have a process in place for deployment. In our case, we have multiple repositories - one for development only, and one for production. All our developers work on the dev repo only, and they have the ability to merge changes to that, which deploys onto our staging servers for testing. However, at this stage, only I have the ability to pull their changes into the production repo and deploy to our production servers.

While a lot of the above can seen like extra hassle if you are just a solo dev right now, I would really encourage you to set up a lot of these 'best practices' as if you were running a team, because then it is super easy to add more developers as your project grows.

Even if your project doesn't grow, at least you know you have secure practices in play which should serve you well.

There are many security controls and lists of such controls that you can refer to if you want to get an idea of what to do and why. For instance: NIST Cyber-security Framework (CSF), SOC 2, CIS top 20, SAFECode, etc.

It's indeed multi-dimensional; you need to think about defense in depth:

• Isolate environments from each other (dev vs production)
• Secure all communications (TLS everywhere)
• Implement mutual authentication between back-end services that need to interact together
• Implement multi-factor authentication
• Use strong ciphers (disable weak ones)
• Add security HTTP headers for your Web apps (Content Security Policy among others)
• Secure cookies (secure, httpOnly, sameSite, etc)
• Implement rate limiting for all endpoints
• Limit size of all payloads (e.g., pagination for collections with max number of items per page)
• Isolate configuration from code (no secrets in your repositories)
• For deployment pipelines, use secure variables and never log any of those
• Use MFA for all of the things you use for development and hosting (AWS, DigitalOcean, source control hosting, etc)

Also need to think about backup/restore, disaster recovery plans (what do we do if ...), security incident response (what if we get hacked?). Also interesting to look into bug bounty hunting programs (better be hacked by the good guys first).

And, of course, there are many concepts/ideas to be aware of and careful about while coding: input validation, output encoding, authentication, authorization, error handling, logging, auditing, data security, data privacy, etc.

And... so much more :D

I'm right in the middle of this as I'm also building a SaaS product and busy preparing a book about software development concepts (including IT Sec).

As a solopreneur, I decided to go serverless with Firebase to minimize security risks. Following their security rule guides and best practices makes me feel pretty good about my app's security. I've really enjoyed using all of Firebase's services (auth, firestore, hosting, cloud functions). It lets me spend 90% of my efforts on the front-end (React SPA) and only 10% on the backend and not have to worry about scalability.

Use managed SaaS products there are a lot out there already that solve these sorts of things implicitly:

• Cloud providers like AWS will get you a lot of the way -- They provide the encryption at rest managed databases you need, as well as secure Load balancing, DDoS protection, TLS certs for encrypted communication
• CI/CD with tools like GitLab help a lot, secure containers or linked managed containers running in your infra.
• Stripe works out of the box, it's hard to go wrong there. They handle both the liability and complexity of PII.
• For application level API security and features Authress solves most of the problems.

I use Rails with battle tested gems such as devisem to do it for me. There's no way I'd be able to roll my own and work on to business too, so why waste my time with the minutae when others have solved it already?

Several people have already commented on several different areas here, but one method for protecting your Node/Express routes is by checking requests for valid tokens.

If you use Firebase authentication, you can use Firebase's own ID tokens to protect your endpoints. I wrote an article on how to do in Node.js/Express in my blog below if you're interested.

https://www.tonyvu.co/posts/jwt-authentication-node-js

As someone that used to hack websites in my teens i can say that there's always a way. But here are a few good rules:

• Keep your stack up-to-date.
• Read about best practices, some specific to your stack.
• Use unique passwords, everywhere.
• Don't store passwords in your code.
• Keep regular backups, in a different server than your web app.

If you're planning to keep financial user data like credit card numbers... make sure you read a book or two about the subject. Otherwise, let 3rd parties like Stripe handle all that.

Lastly, plan as if you will get hacked. Have an easy way to purge and restore everything.

Hey Ricky, great post! This is a favourite topic of mine and it can be a bit of a minefield to navigate at times because everything is constantly changing.

I have been writing a blog post about this, you've inspired me to finally publish it today:

https://blog.usegravity.app/20-hacks-to-secure-your-node-js-web-application/

Another great resource I'd recommend is the PortSwigger academy if you want to get your hands dirty with some practical examples: https://portswigger.net/web-security

Security implementation is different for every project but there are some which are standard across all web apps. As mentioned by @asimon, there are basic that you should at least implement for your project. I'm also here to learn how others are doing it.

From my experience and view, you have to design your implementation based on your startup setup and how customers are use it. e.g

1. Where are you deploying your application (Inhouse, Cloud)? Determine if you need Network and Deployment security e.g SSH, Linux hardening, SSL etc
2. Which services do you use? Nginx, Docker, Kubernetes, Python, PHP, Git - stack security e.g Django best practices etc.
3. How big is your team? You need to implement Access Policy/RoleBased
4. Do you offer APIs? You need to implement Data/API Security

Now doing all this as a startup can be overwhelming, and it will take time. I created https://safeced.com/ to help startups to get this done. Currently I'm working on a simple web app that will help startup founders determine which security to implement and how to implement it. The app will help to prioritize items that should be given priority based on criticality.

This small list will give you idea on what I intend to cover and the implementation:
https://docs.google.com/spreadsheets/d/1IjFWxbLoce6nNfVYliQydd0MlULyX_PQnz8MaK0zoWM/edit?usp=sharing

Please let me know if this is something that you'll like to use/ just see it rolled out.

Thanks.

It may be of interest to some in this thread that, No Starch Press is currently running a security-focused Humble Bundle. Their resources are top-notch. In particular, check out Web Security for Developers: Real Threats, Practical Defense.

Haven’t seen anyone else mention CloudFlare, but they give you https, rate limits and basic bot detection out of the box, for free. Can be installed without changing anything in the code.

Securing a server or an app is a journey and a process, not an event.

You're off to a good start and asking the right questions.

The only real answer is, you keep this in mind indefinitely, when adding new developers, team members, features, etc.

Lots of good tips in this thread, and across the web.

Great replies from all, very useful to many out there. Thanks!

A lot of questions but all very good ones! Here are some simple tips.

OWASP Top Ten 10 is first place to start as others have mentioned - https://owasp.org/www-project-top-ten/

TLS is important, if you're running a VM an not an application platform like Heroku then perhaps try using Caddy for your web server. It's HTTPS by default, is simple to setup with Let's Encrypt.

Using Stripe, or another payment service, will help you protect your users since they will manage all of the sensitive payment information for you.

Protecting user data, APIs, routes, protecting features (freemium...) etc... are all part of scrutinizing and sanitizing inputs. You need to check all data or requests being sent to your web application. Are they valid for the user and their plan? Does the data they're requesting belong to the user? Are the inputs conforming (format, types, etc...) to what you're expecting? Are you sanitizing your inputs, e.g. escaping HTML, JS, etc..

If you're new developing web applications then building over an existing framework can help but there's lot of resources on the web as well to help you.

I know some other people answered, but here are a few additional things to check out:

• Make sure to use parameterized queries in order to prevent SQL injection.

• Make sure anything like a .env file that has keys/passwords (e.g. the file containing a password to connect to your database) in it is not accessible by clients.

• Ensure you're preventing XSS (e.g. can a user input "<script>alert("hi");</script>" and have an alert show up on your site? If so, you're vulnerable to XSS).

It's a valid concern. Although security is such a wide concern that exists already library/services that do this for you. For example for authentication I would use something like firebase or auth0, for persistence I would use a a managed database and so on.
Basically delegate this responsibility to your tools.

Very good responses already here. A few things that haven't been mentioned:

• Use KMS: Always encrypt passwords, keys and pass phrases with a managed service like AWS KMS or GCP KMS. Too often I hear stories about keys being pushed to a git repo in plaintext. 🙂
• Assign roles granularly: Microservices and services that you create will usually have roles assigned. Make sure to give them granular access (e.g. only access S3). Wildcarding permissions * poses a security risk, not only from external actors but if your application code accidentally accesses/deletes something that it shouldn't have and the permissions let it.
• Data retention: Store user data only as long as you need to.

Yeah so there's a lot of things you can and cannot do; trying to summarise some attention points of mine, most of which are focussed at simply closing the front door;

1. Change default passwords, always!
2. Ensure services which do not need internet access do not have internet access.
3. Ensure data sources are not directly accessible/queryable through a service
4. Input validation on the server is more important than input validation on the client side.
5. Never store plain passwords
6. Use encryption where appropriate

As for API design specifically;

• Create consistent and easy to use method to apply proper authorization rules to API endpoints. (See here an example of what I mean; https://corstianboerman.com/2019-12-16/graphql-dotnet-authorization.html)
• As for sensitive data; only write queries which retrieve data for the currently authorized user. You'll prevent accidentally leaking data by generic queries.

As for checking whether a user has paid for something, this is mostly an afterthought, and security wise quite low on my need to check list as it does not directly involve leaking data. Additionally, when you see this being abused by authorized users it may become a trigger to send them an invoice.

For preventing triggering multiple actions you might want to look into a concept called idempotence. It's something Stripe supports in their API to prevent triggering multiple charges for the same thing.

Overall, the more solid your backend is, the more leeway you give yourself on your frontend, and by simply closing the front door you'll save yourself already from most common threats.

Many website these days use WAFs (Web application firewall) which works well in many scenarios. You can use cloudflare WAF with a certain subscription which is used by millons of websites nowadays. Yes, it could be bypassed but they update their database everyday to fix new discovered bypasses.

You should also take a look at web apps penteration testing books to fix the popular vulnerabilites like XSS and Sql injections.

One of the most popular books is Web Application Hackers Handbook
https://www.amazon.com/Web-Application-Hackers-Handbook-Exploiting/dp/1118026470

By the way you can't ensure that your website is 100% safe.Hundreds of vulnerabilites is discovered by white hat hackers on the most popular websites like Uber,twitter and paypal: https://hackerone.com/paypal
https://hackerone.com/twitter
https://hackerone.com/uber

You could either self-teach through online resources/course/books or find a developer with experience in securing production applications to work on your project.

Searching for "Node Express Security" gives some good places to start learning:

• https://expressjs.com/en/advanced/best-practice-security.html
• https://owasp.org/www-project-top-ten/2017/
• https://blog.risingstack.com/node-js-security-checklist/

I would say for each piece of tech you're using (language, framework, database, operating system) you should lookup how to make it secure. You just need to invested the time in learning about security.

The way I learnt was using recommended best practices to build my apps, casually reading about how sites were compromised on places like hacker news and reading up on their vulnerabilities, and actually dedicating time to learning about how to make my applications secure.

How do you ensure that your Stripe payments is secure? What if the user presses the checkout button multiple times resulting in multiple charges?

This is covered by the stripe API. U only get 1 handlePaymentIntentSucceeded, though it might be delivered multiple times in rare cases so you should make actions on success idempotent.

I wrote a ton about all these topics here https://observablehq.com/@tomlarkworthy/saas-tutorial