Common Mistakes Developers make, when it comes to Security

Consider you are in the middle of a party and you get a call from your boss that your job is at stake because of the security flaw you made in your code. Worst Nightmare, right?

Today we are going to talk about the common mistakes developers make when developing an application. Whether the application is small or big when you make your code vulnerable then you are doing something wrong. Don't worry, I have shared some of the best practices we follow to keep the code secure.

Problem 1:

Hardcoding Third Party Secret Key & API key at App level or Front end.

This is one of the common mistakes developers do by hardcoding the secret key or API key at App level or Frontend code, usually we think who is going to take it or see it. It may be perceived less vulnerable when it comes to no impact on your business. But consider you have hardcoded your 'twillio' or 'sendgrid' secret key or API key, then BOOM someone will use your service.

Solution

All the third-party service should be consumed by your backend application, whichever you have decided to go with.

Problem 2:

Saving sensitive information at App Level, Cookies

Solution:

Always encrypt or hash the value, even its less secure value. Keep in mind every value is of some significance to someone. If you are saving in the local database, try to encrypt the whole database or encrypt the value and save it.

Problem 3: Leaving your backend application UnSecured.

This is another problem where developers think backend is really backend, when in reality it will be visible at browser or app level. Hackers can get access to your backend in a matter of minutes, believe me, it is doable.

Solution:

All your backend applications should be HTTPS, no HTTP There are many ways to secure your backend app, following are few of the options.

1. Secret key or API Key for your backend application (Less secure, if its the only backend for your frontend, again you will run into problem 1)
2. Ip whitelisting of who can access it (This will be useful when your backend will be accessed only by another backend, again this will not be useful when you have a front end)
3. Client Certificate authentication
4. Oauth 2.0 (Recommended Approach and Highly Secured)

Oauth 2.0 is a winner when it comes to securing your backend application from the frontend.

In olden days, when some application requires access through your Gmail, they will simply ask you to type your Gmail account and Gmail password to access your Gmail or google photos etc, in which you are sharing your sensitive information to some third-party application where you will not know how they are going to use it. Weird right? But we used to live in those days.

So Oauth was born, where your application will request for access rights from Gmail and Gmail will give you an access token, through which you can access Gmail with some level of restriction. Eg: Your application wants to read the Gmail inbox. You request Gmail with Read access for Gmail inbox and you get back an access token. You might think, now that I acquired an access token I will try to Write emails with it, but this is where OAuth will intervene and stop the action.

I hope the above explanation helps you understand OAuth usage. There are many players in the market related to IAM, Authentication. I have listed a few for you:

IAM:

• mIdentity.one (Paid, cost-effective when compared to others)
• Auth0 (Paid)
• ForgeRock (Paid, for large consumers)

Opensource:

• Keycloak (RedHat)
• Gluu etc., I will update this space if I find more

I will explain more on OAuth in the upcoming blogs :)