How to minimize security concerns in your applications

TL;DR style notes from articles I read today.

Securing REST APIs

• Ensure that you only accept queries sent over a secure channel, like TLS.
• Use API keys to secure, authenticate and track usage of a REST API.
• Validate parameter-based inputs for queries. 
• Whitelist permitted HTTP methods and block those accessed via a public API.
• Authenticate individual users for specific actions. 
• Log all failed requests and look for patterns to identify sustained attacks. 
• Use a security framework with policies to decide whether the querying party can see the data.

Full post here, 6 mins read

---

How to minimize security debt from the start

• Retrofitting security issues requires that you refactor not only code but also human behavior.
• Take stock and build an inventory of all connected devices and applications within your network, locate where all data reside, and audit access to them.
• Secure data travelling within as well as across networks.
• Take special care to secure DevOps projects as they introduce considerable security risks.
• Establish an access management policy that evolves as your organization grows.
• Encrypt data (in rest and in motion), use multi-factor authentication, ensure redundancy, and segment data and systems.
• Build a good incident recovery plan right from Day 1. 


Full post here, 5 mins read

---

How to combat cloud software security threats

• Deploy strong identity management and access management systems.
• Understand how security works with third-party apps & integrations in detail. Ensure you know what exactly does granting access for anything to a third-party app means.
• Ensure that your cloud vendor provides audit logs and check them regularly.
• Check that your cloud software vendors are compliant with the widely accepted standards & regulations pertaining to your industry. Consider security assessments by third parties as well.
• Look for how seriously your cloud & cloud software vendors take their bug bounty programs.

Full post here, 5 mins read

---

Get these notes directly to your inbox every weekday by signing up for my newsletter, in.snippets(), here.

Comments

[Paulo Renato]

Many thanks for sharing such a very nice post about security in several fronts, with links for the resources.

I would like to make some calls of attention for the readers, but please do not take this as an attack, just as complimentary information.

Authentication vs Authorization

Authenticate individual users for specific actions.

• Even when a user is already Authenticated, its good practice to Re-Authenticate and Authorize the user to perform a specific action in sensitive data, like changing the email or password.
• Always remember that Authentication is not the same as Authorization. You may prove that your are Bob by passing the login challenge successfully, but that doesn't mean you are Authorized to perform the action you are trying to.

API Keys are not Secure

Use API keys to secure, authenticate and track usage of a REST API.

Lets' clear first a usual misconception among developers, that relates to WHO vs WHAT is accessing the API server.

For a better understanding off the difference between WHO vs WHAT is accessing your API server, I recommend you to read this section of my article, but I will extract here some lines of it:

The who is the user of the mobile app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.

The what is the thing making the request to the API server. Is it really a genuine instance of your mobile app, or is a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?

API keys do not truly Authenticate anything, at best they can be used to track usage, and impose rate limits. They are not a secret, because once they are in a web app or mobile app, they belong to the public domain, thus they cannot be used for the purpose of authentication, because they are easy to extract and reuse in automated or manual attacks.

[jappyjan]

Im with when it comes to security of api-keys, with one difference. They can be secure (or at least as secure as things can be ;) ) as long as they are bound to the session/client who created them, which would result in a broken key if someone would try to reuse the same key on another device/session.

[Paulo Renato]

Sessions can be reused by an attacker, but definitely it makes up for one more security layer to be bypassed, and I always recommend to use it when possible.

Other techniques exist to make them more difficult to abuse, but an API key on their own, can only be considered secure for authentication purposes when the communication is between 2 servers, and they are stored in both servers in a secure way.

[Arpit Mohan]

Thanks for the detailed response. Definitely very helpful! I agree with all your points.

W.r.t API Keys, I am also of the opinion that once they are included in a webapp or mobile, they are in the public domain. As @exadra37 mentions in the chain, typically API keys (in plaintext) are used for server-server communication. Whenever including API keys on the client side, one should always sign & encrypt the token with the client's private key before transmitting over the wire. They then just act as session IDs.

[Paulo Renato]

Whenever including API keys on the client side, one should always sign & encrypt the token with the client's private key before transmitting over the wire. They then just act as session IDs.

Signing anything with a private key on the client side can be bypassed, because once you have the private key in the client side, aka mobile app or web app, it's not anymore a private key, it's a public key.

Now signing and encrypt an API key token on the server side, before it's sent to the client guarantees confidentially during the communication process and allows to anyone having the server public key to verify its authenticity, but doesn't guarantee that when the API key token its sent back to the server that it comes from the same client the server sent it to, because an attacker may be reusing it to impersonate the server as the original client.