What Is CORS?

CORS is a browser protocol and security standard. It is critical for API development. To limit the hazards of cross-origin HTTP queries, modern browsers use CORS in APIs such as XMLHttpRequest or Fetch. It allows you to keep your website’s integrity. But what exactly is CORS? What is its purpose? All of the information is provided in this article.

What Is CORS?

So, what exactly is CORS? CORS is an acronym that stands for Cross-Origin Resource Sharing. It is a browser technique that allows controlled access to resources outside of a specific domain. As a result, static content can be hosted at “www.nilebits.com” and the backend API at “api.nilebits.com.” A resource from one domain requests a resource from another domain in this situation. This type of request is referred to as a CORS request.

CORS, on the other hand, can expose your site to potential cross-domain attacks if not properly configured and implemented. As a result, you are very likely to encounter various security threats, such as cross-site request forgery. As a result, you must exercise extreme caution when configuring CORS.

How Does Cross-Origin Resource Sharing Work?

In the pipeline for Cross-Origin Resource Sharing. A script loaded from one origin tries to send a request to another.

The browser sends a preflight request to the external web server using the HTTP method OPTIONS. There are numerous headers in the preflight request. The headers are validated by an external web server. It ensures that only scripts from the specified origin can make the actual request. They make use of the specified request method and custom request headers in the preflight request headers.

Following the completion of the verification, the external web server will respond with its own set of HTTP headers. These headers specify the permitted origins and request methods. It also specifies whether any credentials, including cookies and authentication headers, are acceptable. Furthermore, it allows you to specify how long the browser should keep the response.

What Are The Access Control Request Headers, And What Do They Do?

The Access-Control-Request-Headers header is of the request type. Browsers use it when sending a preflight request. It informs the server about which HTTP headers the client may send when making the actual request.

The operation of access control request headers is simple. Let’s take a closer look.

• Origin – It’s the domain or subdomain that the script making the request was served to the browser from.
• Access-Control-Request-Method – It’s the method that the script utilizes in the actual request to follow.
• Access-Control-Request-Headers – These are custom headers. The browser expects to send them along with the actual request to follow.

What Are Access Control Allow Headers?

The HTTP Access-Control-Allow-Headers is a response-type header. It is used to indicate the HTTP headers.

What Are HTTP Request Headers?

An HTTP request header is a network packet component. It is delivered to the server by a browser or client in order to request a specific page or data.

The HTTP request headers linked with the requesting domain are listed below.

• Origin
• Access-Control-Request-Method
• Access-Control-Request-Headers

What Is CORS – What Are The Different Types Of Headers?

• Access-Control-Allow-Origin – Access-Control-Allow-Origin reflects the “Origin” request header’s content provided that it matches your access list.
• Access-Control-Allow-Credentials – Access-Control-Allow-Credentials is a Boolean header. When set to true, it tells browsers to expose the response to the frontend JavaScript code. The credentials consist of cookies, authorization headers, and TLS client certificates.
• Access-Control-Expose-Headers – The Access-Control-Expose-Headers is an HTTP response header. It determines which headers are to be exposed to the client scripts on the web.
• Access-Control-Max-Age – The Access-Control-Max-Age is a header request. It determines how long the browser should retain the response to the cross-origin request’s preflight check in its cache. It helps you reduce the overhead of future cross-origin requests.
• Access-Control-Allow-Methods – The Access-Control-Allow-Method is a response header. It specifies one or more methods allowed when accessing a resource in response to a preflight request.
• Access-Control-Allow-Headers – The Access-Control-Allow-Headers is another response header. It is used in response to a preflight request that includes the Access-Control-Request-Headers. It helps you to determine which HTTP headers can be used during the actual request.

Are There Any Caveats For Using The “access control allow” Headers?

The request headers are more sophisticated than the “access control allow” headers. Because most browsers do not implement the standard properly. But what are the reasons for this? Let’s find out who they are.

Access-control-allow-origin

At first appearance, the Access-Control-Allow-Origin header appears to support a comma-separated list or a wildcard subdomain. You believe you can set them statically to match all domains and subdomains. You believe it would significantly minimise the number of times the browser must do preflight requests during a session. Unfortunately, this is not the case. It will result in unpredictable behavior. It, for example, supports a generic wildcard, which can completely disable the check in the browser. As a result, user data will be vulnerable to security threats.

What’s The Issue With The Wildcard?

When you set “Access-control-allow-origin” to “*,” the same-origin policy is disabled. As a result, the browser will allow practically any request to the cross-origin resource from any script. It can lead to a variety of problems. The browser, for example, will no longer filter the origins. As a result, phishing sites can send a request to the resource. It’s something you never want to happen.

You may be considering copying and pasting wildcards from popular forums. You believe it will assist you in appropriately using credentials such as Authorization HTTP headers or cookies. However, they will cause your cross-origin request to fail. Because browsers prevent you from setting the “access-control-allow-credentials” header if the “access-control-allow-origins” header is set to a wildcard.

How About Reflecting Just The Origin?

You might consider reflecting only the origin. It appears to be a wise strategy. However, it completely circumvents the browser’s ability to prevent the “access-control-allow-credentials” header and “access-control-allow-origins” wildcard from being set.

Principals Of A CORS Attack

The nature of the misconfiguration determines the risks of an attack. It also depends on how you authenticate requests.

Types Of CORS Misconfigurations

There are two main types of CORS misconfigurations. They are

• Access-Control-Allow-Origin (ACAO): ACAO facilitates two-way communication with third-party websites. Any misconfiguration in it can exploit sensitive data, like usernames and passwords.
• Access-Control-Allow-Credentials (ACAC): ACAC allows third-party websites to execute privileged actions like the authenticated users. For example, it enables the sites to change the password and contact information.

Impact And Risk

A faulty CORS configuration can expose your application to high-risk security attacks. It enables third-party sites to carry out privileged requests via the authenticated users on your website. As a result, it will have a substantial influence on the confidentiality and integrity of sensitive data. Third-party sites, for example, can retrieve the user’s saved credit card information.

The risk is low, however, for applications that deal with public data and require resources to be sent to other origins. However, penetration testing is required to determine the appropriate risk level.

What Is The Best Practice To Enable CORS?

Valid requests must be made to the cross-origin resource. You must also guarantee that the browser does not allow every script that it loads. All access control request headers should be validated against relevant access lists. However, it can be difficult to implement, particularly with the origin header. Furthermore, the web is littered with small misconfigurations in parsing routines and improper regex. It exposes several sites to security risks. However, by keeping it basic, you can accomplish it safely. You can, for example, compare a secure string to an array of trusted values. If it does not match, a “403 Forbidden” answer will be returned.

You may want to back more than one “Origin.” However, until browsers offer a list of origins in the “access-control-allow-origin” header, you won’t have many options. However, the validated “Origin” request header might be reflected in the “access-control-allow-origin” header.

Libraries, Frameworks, & Reverse-Proxies

Most programming languages and web frameworks include a pre-built mechanism for dealing with these challenges safely. As a result, you do not need to exert additional effort. However, only a few languages and frameworks provide proper validation. As a result, you must validate the library’s operation. If everything is in order, you can begin using it.

You might also use an established web server, such as Nginx or Apache, as a reverse proxy. You can use its filter rules to reflect the headers as long as they pass the validation. Keep in mind, though, that they use regex. As a result, you must exercise extreme caution when crafting the search string. It will assist you in doing the validation safely. Many people make mistakes when typing in the search string. As a result, they do not achieve the desired effects.

How Can You Enable CORS On The Origin Server?

To enable CORS for static resources such as CSS, fonts, JavaScript, and images, add the following code to your server:

Apache

<IfModule mod_headers.c>
    <FilesMatch "\.(ttf|ttc|otf|eot|woff|font.css|css|js|gif|png|jpe?g|svg|svgz|ico|webp)$">
        Header set Access-Control-Allow-Origin "*"
    </FilesMatch>
</IfModule>

Nginx

location ~ \.(ttf|ttc|otf|eot|woff|font.css|css|js|gif|png|jpe?g|svg|svgz|ico|webp)$ {
    add_header Access-Control-Allow-Origin "*";
}

IIS

 <system.webServer>
    <httpProtocol>
      <customHeaders>
        <add name="Access-Control-Allow-Origin" value="*" />
        <add name="Access-Control-Allow-Methods" value="GET,PUT,POST,DELETE,OPTIONS" />
        <add name="Access-Control-Allow-Headers" value="Content-Type" />
      </customHeaders>
    </httpProtocol>
  </system.webServer>

Does Cross-origin Access Control Allow More Freedom?

Yes, it provides more flexibility and functionality than purely same-origin requests. It is also more secure than simply allowing all cross-origin requests.

What is CORS and how does it work?

CORS is an HTTP header-based mechanism for cross-origin resource sharing. It enables a server to indicate any origins other than its own, such as a domain, scheme, or port. It allows the server to whitelist specific origins explicitly. As a result, they can get around the same-origin policy.

What is an example of CORS?

Consider a scenario in which you can host static material at a domain such as www.nilebits.com. You can host a backend API at a subdomain, such as api.nilebits.com. A resource from one subdomain is seeking a resource from another subdomain in this case.

What is CORS in web API?

Cross-origin resource sharing (CORS) is a security feature of browsers. It prevents cross-origin HTTP requests initiated by scripts from being executed in the browser.

Is CORS really needed?

Yes, CORS is essential. It’s an important protocol for allowing cross-domain requests. It enables you to whitelist requests to your web server from specific IP addresses. Response headers such as ‘Access-Control-Allow-Origin’ can be specified.