Web Pages— Basic Security Practices

The security is always #1 priority for all types of enterprises and yet there are few common mistakes that teams end up doing time to time unknowingly.

One of the attack that requires special attention is “credential stuffing” in which hackers get the access of the user credentials such as email id and password from dark web or form less secure sites and then use this information for launching scripted attacks across multiple target sites.

Source : https://www.cloudflare.com/learning/bots/what-is-credential-stuffing.

The reason why “credential stuffing” works is because of the fact that most customers have the habit of reusing the password across multiple sites.

There are few patterns to prevent “credential stuffing” attack such as Two-Factor Authentication but in this article we will focus on simple approaches that could be followed by development team for reducing the risk of data breaches.

Approach #1 : Mask Data On The Server Side

Most websites use data masking as a common technique for securing the customer’s sensitive data such as Tax ID, Passport Number etc.

Social Security Number : XXX-XX-4759

Date of Birth : XX/XX/1985

Masking requires minimal efforts but helps significantly in ensuring that sensitive information is never compromised even in case of attacks like “credential stuffing”.

Anti Pattern: Client Side Data Masking

If data is being masked on client side than hackers can still launch scripted attack and parse response for accessing sensitive customer data so always do server side masking.

Approach #2 Avoid oversharing of the customer information to front-end pages

Web Applications usually make back-end APIs call to load information that is required to be displayed to the customer and most of times, these back-end APIs response includes superset of the information as a default behavior.

E.g. In an e-commerce app, if front-end page has to display customer’s name and address and it makes a back-end api call using customer id then api should only return name and address field. The API response shouldn’t contain phone number, date of birth, gender and other personal information.

This approach ensures that if attackers are able to access a specific web page using “credential stuffing” then they would have limited access to sensitive profile information.

REST APIs usually return the entire resource (e.g. Customer details) in response as a default behavior so this mistake is more common as front-end team just ignores the unwanted additional fields. On the other hand, GraphQL APIs forces both front-end and back-end developers to plan for fields level queries explicitly.

Approach #3 Dynamic URLs for front-end pages

Static URLs have several advantages over dynamic urls but there are few use cases where it’s worth considering the usage dynamic urls for improving the overall security of the urls as it makes it difficult for hackers to launch scripted attacks.

Static URL — www.example.com/dosomething

Dynamic URL — www.example.com/context_id={context_id}

As an example, If there is a use case that requires urls to be mailed out to thousands of customers and if this url is going to display sensitive personal info and/or collect some personal info from customers and then it would be better to use dynamic url like as it makes it difficult for hackers to use “credential stuffing” attack for all customers as urls are different for each of them.

These guidelines are not comprehensive and wouldn’t make web pages full proof but these approaches can be implemented with small efforts for reducing the impact of data breaches !!!