Web Security Basics

Cybersecurity is a huge topic which you can carve your own career from.

For example, many big companies have their own cybersecurity experts to protect against many forms of attacks, such as: phishing, malware, ransomware, Denial-of-Service (DoS) attacks and SQL injection.

Of course there are also social engineering attacks for which may render the cybersecurity expert helpless. For example, this relates to copying work passes posted publicly on LinkedIn, and pretending to be an employee to gain physical access into a company.

Therefore, there are numerous ways to breach the data security of a company. A good way of looking at it is that nothing is "unhackable" but you must do everything in your power to make it so. Although cybersecurity is its own discipline, there are a few things you can do or at least consider, to give your website at least a basic level of protection. But where do you start?

One helpful resource is the Open Worldwide Application Security Project (OWASP). It is an open source community that provides free resources in relation to cybersecurity. One of its main pages is the, Top 10 Client-Side Security Risks . It was published first in 2003 and is regularly updated, detailing the latest risks and how to protect against them.

A helpful level of protection is the Content Security Policy (CSP). This prevents data injection attacks and cross-site scripting (XSS) , by specifying which type of resources are allowed to be loaded on a web page. For example, with CSP you can prevent users from injecting their own script onto your webpage. Also, if you have given the appropriate endpoint, you can report a violation of the policy. Or in other words, when a user attempts to unleash a malicious script on your webpage, it blocks and reports it.

Cross-Origin Resource Sharing (CORS) is also a protective measure. This allows web browsers to make requests to a server on a different domain. The default behaviour of a web browser is the Same-Origin Policy, which prevents scripts from one domain accessing resources from another domain. Through this measure, it stops malicious scripts from stealing data or compromising user privacy. However, apps such as Single Page Applications (SPA) often have to send requests to a resource on a different domain, such as an external API. In this case the browser sends a CORS request which contains the origin of the request and web domain. If the server hosting this API is not setup to receive CORS request, access will be denied.

Another commonly known security measure is the Hyper Text Transfer Protocol Secure or HTTPS. Originally, data was sent between the client and the server on just the Hyper Text Transfer Protocol (HTTP). This data would be sent as just plain text and it was vulnerable to interception. In addition there is no authentication meaning that there is no verification of the website or server. If you were on such a website, for instance, and paid for a product, hackers could intercept the request when you made a payment and have access to your credit card details.

On the other hand, HTTPS provides a much more secure data transfer. In the same example if you paid for a product on a HTTPS website, that same data in the request would be encrypted via Secure Sockets Layer/Transport Layer Security. Furthermore, the website's identity is verified with a digital certificate, authenticating that it's trusted and not a malicious clone.

Another common practice to protect your data is by using environmental variables or env values. These would sit somewhere in your backend holding the keys to your database system. Without these values, you won't have access to add, edit, remove or read data from the database. Despite it being common practice to hide these values, there are cases whereby companies have accidentally exposed these env values . As mentioned before, this can be catastrophic if published publicly on GitHub due to the prevalence of malicious scraper bots . When you have access to these keys, you can manipulate the database however you see fit.

There are of course many other forms of protections, but the list is indeed endless.

You can work to implement as much protective measures as you can, but at some point, you might find that it is impacting your productivity on developing the actual application. In some ways it makes sense to prioritise its security particularly if your app contains sensitive data. On the other hand if your application is more say 'playful' and has no sensitive data, you'd be forgiven for not making cybersecurity a priority. In addition you can always pay for a software or access to a secure API, if you are concerned with handling sensitive data. For instance, a lot of small companies that handle financial transactions use the Stripe API . Not only does this save time, it also places the burden of handling this type of data on another (trusted) party.

The pure vastness of cybersecurity is why some companies dedicate even whole departments to it, but everything is contextual and it doesn't mean you should do the same.

Just ensure you have implemented the absolute essentials - unless cybersecurity interests you, in which case, dive in and make an impenetrable fortress.