November 24, 2020

How do I know, if my chosen security solution is enough (as a software engineer)?

Hi all,

I’m a software engineer who wants to launch his own product. I write that, because my business partner demands a good security system and I’m not really sure if my planned security measures are a good standard. I’m really afraid getting hacked and disappointing my customers and business partners – that’s the reason why I’m asking on this thread. I came so far with my own knowledge and research and therefore wanted validation or some other tips.

My security measures:

– Implement token based authentication with jwt ([](
– Secure the connection with SSL
– Follow the OWASP top ten web app security rules ([](
– Probably at a later stage, look more into Firewalls and DDoS protection, because at the beginning I doubt that someone will DDoS us with a few customers and the standard firewall will probably be enough.

What is your opinion? Do you think it’s missing out on some crucial things or do you think it’s a solid foundation?




Just clarifying here. You’re launching a WebApp and want feedback on the Security Architecture you’re planning on implementing?


>I write that, because my business partner demands a good security system

**Might want to start with what “good security” means.** This is paramount before continuing on. “Security” can cost time/money and can slow things down (I wish it weren’t so, but there is always a trade-off).

Figure out what the goalposts are before driving towards the net.

This is can be a huge topic, but I’ll give some outlines.

**Obligatory disclaimer:** I’m just a guy from the internet. People will agree or disagree with me as they want. Take this with a grain of salt and do your own research.


1. **Take a risk-based approach:** You can’t protect everything from everything. You have a limited budget and security controls get expensive. You wouldn’t spend $1 million to protect a $1 investment. **This means figuring out what the “crown jewels” of your app would be and making sure they are protected.** If you got hacked would it mostly just be “egg on your face”? Or would important trade secrets or personal information get disclosed?
2. **Make security part of your requirements elicitation:** This means that when you talk to your customers and they ask for features, bells, whistles, whatever, you consider the security implications **every time** a request comes up — make sure it is ingrained in all employees. Think “how could this be used to attack my system or get to the crown jewels?”
3. **Build security into the system from the get-go:** That means don’t just take any library/framework you find and jam it into the system. Who else uses that library? Is it known to be Swiss cheese security-wise? How often is it updated — do I need to plan for those updates? It is WAY harder/impossible to retro-fit security into an existing system. Think about the architecture and know that complexity usually means more bugs. More bugs means more potential ways to exploit. K.I.S.S. Look up best practices for secure software development. This is where you would consider those OWASP top 10, how to securely communicate with clients (SSL, certs (plan for renewal? put it in your calendar)). [Have security checks in your CI using OWASP zap]( or whatever you can — look for tools that do this.
4. **Vulnerability Management — Plan for it:** In essence, **patch your shit!** First thing attackers will do is try to find out what versions you are running and look up vulnerabilities for it. **Patch. Your. Shit — And have a plan from the beginning to do so (doesn’t have to be complicated**, just consider it). Consider the longevity and patch cycles. How are you going to update this thing? If it is Python-Django (as an example) you better have a plan to learn about patches and upgrade the framework/plugins/versions, etc.
5. **Keep security at the forefront:** Keep it in the company culture. This doesn’t mean that security “wins” every time, it means that you are considering it and discussing it regularly with respect to your product. Don’t let it get pushed to the side easily, and make sure security compromises have justifications.
6. Look into hardening guidelines for the systems/OS’s/Tools you use. It might help.
7. Logs. Have logs. Check them. Don’t let them collect dust.
8. **Don’t roll your own crypto**. Don’t. No special encryption. Avoid **manual** salting and hashing (But if you store passwords you damn-well better be using a framework that salts and hashes them). Use a framework that has all that built in. Save yourself time and pain.

This might seem like a lot, but it really boils down to **having a plan, thinking about (and acting on) security before doing things/writing code, and keeping the security conversation going**. Triage this. Make a prioritized list (cost, effort, complexity, etc.) and start at the top. You can’t do everything so make it realistic.

Plenty more could be added, this is just a high level overview. If your business partners are paranoid about security — or if you hold a lot of risk — maybe consider hiring a security consultant.

Leave a Reply

Your email address will not be published. Required fields are marked *

Note: By filling this form and submitting your commen, you acknowledge, agree and comply with our terms of service. In addition you acknowledge that you are willingly sharing your email address with AiOWikis and you might receive notification emails from AiOWikis for comment notifications. AiOWiksi guarantees that your email address WILL NOT be used for advertisement or email marketting purposes.

This site uses Akismet to reduce spam. Learn how your comment data is processed.