Angular Security Fundamentals

This blogpost covers the following areas:

• Angular and OWASP Top 10
• A dive into three important and fundamental security concepts

Angular and OWASP Top 10

OWASP stands for Open Web Application Security Project. The OWASP Top 10 is a list you need to know, as it is a list of web security risks from the OWASP foundation. It tells you where to focus your security effort, as it represents the most critical risks. The list gets updated every 3–4 years.

Here’s a direct link for you: https://owasp.org/www-project-top-ten/

Now — we are going to cover three security concepts.

Fundamental security concepts

The following three security concepts must be known to understand what is allowed in the browser and how it works. Therefore — we’ll examine those in the section below.

• Same-Origin Policy (a.k.a. SOP) — How one origin can interact with another. It limits how one origin can interact with other origins. An origin consists of a protocol, domain and port, eg. https://google.com:443. In a same-origin policy, reads are typically prohibited across origins, and writers are typically allowed across origins. Embedding is generally allowed when embedding scripts, CSS and images thus are normally a common attack surface as well.

• Implicit and explicit authentication means that the authentication is based on something the browser automatic and implicitly sends on each request. Eg: cookies, HTTP basic auth and TLS client certificates. Implicit authentication is problematic since it is possible for an attacker to do authenticated writes on behalf of a user. It is possible when the servers are not explicitly protecting against this — eg. Cross-site request forgery attacks). Explicit authentication means manually and explicitly sending the authentication token by the developer, eg. Via an HTTP header. The most common way to do this is by using OAuth bearer tokens in the headers. Send auth token using HTTP interceptor in Angular apps.
• Cross-origin resource sharing — How to allow for exceptions to the SOP. Cross-origin resource sharing is a mechanism controlled by HTTP response headers on a server. It is a mechanism allowing origins to perform so-called “non-HTML form compliant”-requests to the server, and relax the SOP. On such request, the browser will first do a preflight request (for loading the CORS headers) and then do the actual request. The browser automatically sends the preflight if this is a cross-origin-non-form-request for reading the Access-Control-Allow-Origin header. The client will proceed with the actual request if the CORS header is present and valid (it needs to either contain the client’s origin or *).

What is a non-form compliant HTTP request? It is a request that contains custom headers or content-type other than the standard HTML form content types.

Eg.: application/x-www-form-urlencoded or multipart/form-data or text/plain.

Best practice when it comes to cross-origin resource handling is to whitelist the origins, which is permitted to call the server instead of using wildcard *.

• Don’t: Access-Control-Allow-Origin: *
• Do: Access-Control-Allow-Origin: https://somedomain.com

What if I want to learn more?

The next step in this area of Angular Security could be learning more about principles and threats that relate to Angular Security. I’ll recommend you to dive deeper into security principles, and it could be the following four:

1. Cross-Site Request Forgery

2. Sensitive Data Exposure

3. Cross-site Scripting

4. Using Components with Know Vulnerabilities

Keep up studying the security area — it is truly important!

About Me

My name is Sarah Poulsen and I am a Business Consultant at Bankdata.