In this era of digital information, web security is one of the crucial aspects of the web apps. Due to their wide spread availability and accessibility, web applications are vulnerable to a variety of attacks, such as cross-site scripting (XSS), SQL injection, and file inclusion attacks.

A bug was reported to LinkedIn, regarding the issue which allowed users to delete any published content that was not even published by that specific user.
It is a classic example of access control issue
Click here to read more...

To ensure web application security, it's essential to implement various measures inorder to build a safe and secure web application. I have listed down the crucial measures that are build safe web apps. Let's go over each concepts and understand how it helps to reach our goal.

1. Authentication and Authorization

Authentication is the act of validating that users are whom they claim to be. This is the first step in any security process.

The authentication can be implemented with various methods based on the needs of the application, it can be as simple as OAuth with JWT tokens or it can involve SSO with OpenID Connect, SAML, etc. A strict authentication process would be an absolute neccessity for building secure apps.

Authorization is the process of giving the user permission to access a specific resource or function. This term is often used interchangeably with access control or client privilege.

The means of access control is highly coupled with the business needs. The Object Level authorization would also be an absolute neccessity for our goal. An ideal access control should be have an resource level (API level) privileges \products and as well as data access level privileges with different write, read access.

2. HTTPS (SSL/TLS) and Data Security

Secure REST services must only provide HTTPS endpoints. This protects authentication credentials in transit, for example passwords, API keys or JSON Web Tokens. It also allows clients to authenticate the service and guarantees integrity of the transmitted data.

The sensitive data should be stored properly by employing various techniques such as encryption, hashing, etc. For example, the password hash can be stored instead of storing the actual password. The encryption keys, hash keys and salts should be stored safely and should not be revealed under any circumstances.

3. Input data Validation

The input payloads of the API should be promptly validated before the actual execution of the API.

• Do not trust input parameters/objects.
• Validate input: length / range / format and type.
• Achieve an implicit input validation by using strong types like numbers, booleans, dates, times or fixed data ranges in API parameters.
• Constrain string inputs with regexps.
• Reject unexpected/illegal content.
• Make use of validation/sanitation libraries or frameworks in your specific language.
• Define an appropriate request size limit and reject requests exceeding the limit with HTTP response status 413 Request Entity Too Large.
• Consider logging input validation failures. Assume that someone who is performing hundreds of failed input validations per second is up to no good.

4. Security headers

There are a number of security related headers that can be returned in the HTTP responses to instruct browsers to act in specific ways. However, some of these headers are intended to be used with HTML responses, and as such may provide little or no security benefits on an API that does not return HTML.

The following headers should be included in all API responses:

These headers are highly configurable, so make use of this flexibility to allow the least privileges that are required for the users.

5. Cookie security

There are several use cases where we use cookies to store relevant information, such as session, tokens, CSRF tokens, etc. In order to enforce the cookie security, we have several attributes which can be set. They are listed as follows,

6. Error handling

We should be using classic error mapping techniques show an generic error messages to client. We should be avoiding detailed techincal information such as tracebacks, sql errors, system errors, etc.

If an error occurred based on the input payload, then we can raise a custom generic message such as HTTP 400 - Bad Request or HTTP 500 - Internal Server Error

7. Audit logs

Write audit logs before and after security related events. Consider logging token validation errors in order to detect attacks. Take care of log injection attacks by sanitizing log data beforehand.

8. Up-to date images and libraries

As in the microservices era, we would be using docker images from public repositories and we also install the required packages. The outdated versions of utils/libraries would create a potential vulnerability that waits to be exploited. Hence we need to take care of these issues as well.

This is not a one time activity, new bugs/issues would always pop in and we need to routinely check and resolve these kinds of issues. There are lots of scanners available as open source in the market, figure out the best tool that suits for the application and get to know about these types of vulnerabilities.

Here's a good scanner, Clair - Vulnerability Static Analysis for containers - Github

By strictly following all these approaches, we should be able to build a secure web application. This should be able to fend of possible attacks if it is hosted in a secure network behind the firewall. Even though we employ all these techniques to create a safe systems, the responsibility equally boils down on the developers who has to write the code without any bugs.

THANK YOU FOR READING
I hope you found this little article helpful. Please share it with your friends and colleagues. Sharing is caring. Connect with me on LinkedIn to read more about Python, Architecture design, Security, and more…!