CORS

# What is CORS ?
CORS (Cross-Origin Resource Sharing) is a security feature
implemented by web browsers that controls how resources on
a web page can be requested from another domain (or origin).
It is designed to prevent malicious websites from making
unauthorized requests to your website using the user's
credentials.

# Why is CORS Implemented ?

CORS (Cross-Origin Resource Sharing) is implemented primarily
as a security measure and to allow controlled cross-origin
resource sharing in web applications. Here's why it is necessary
and important:
 To Enforce the Same-Origin Policy (SOP)
 To Enable Controlled Resource Sharing
 To Protect Against Malicious Cross-Origin Requests
 To Facilitate Modern Web Architecture
 To Maintain User Privacy and Data Integrity
# Methods To find CORS
CORS (Cross-Origin Resource Sharing) is a security mechanism
that restricts web pages from making requests to a different
domain than the one that served the web page. However, when
misconfigured, it can lead to vulnerabilities. Here are several
methods to identify and exploit CORS issues:
Manual Testing:
 Inspect Network Requests
 Modify the Origin Header
Automated Tools:
 Burp Suite
 OWASP ZAP
Exploiting CORS Vulnerabilities:
 Data Exposure
 Cross-Site Scripting (XSS)
Mitigation Techniques:
 Strict Origin Checking
 Credential Sharing
 Input Validation and Sanitization
 Regular Security Audits
# Impact And Mitigation Measures Of CORS
Impact of CORS
While CORS is essential for web security and resource sharing,
its implementation can lead to challenges for developers and
users. Below are the potential impacts and corresponding
mitigation measures:

1. Impact: Limited Cross-Origin Requests

 Description: By default, browsers block cross-origin
requests unless the server explicitly allows them. This may
prevent web applications from accessing necessary APIs or
resources hosted on other domains.
 Example: A frontend app hosted on
https://frontend.example.com cannot fetch data from
https://api.example.net without proper CORS headers
from the API.
Mitigation Measures:
 Configure the server to include appropriate Access-
Control-Allow-Origin headers.
 Use wildcard (*) for public APIs or specify trusted origins
for private APIs.
 Host the frontend and backend on the same domain or use
a reverse proxy to avoid cross-origin requests.
Impact of CORS
While CORS is essential for web security and resource sharing,
its implementation can lead to challenges for developers and
users. Below are the potential impacts and corresponding
mitigation measures:

1. Impact: Limited Cross-Origin Requests

 Description: By default, browsers block cross-origin
requests unless the server explicitly allows them. This may
prevent web applications from accessing necessary APIs or
resources hosted on other domains.
 Example: A frontend app hosted on
https://frontend.example.com cannot fetch data from
https://api.example.net without proper CORS headers
from the API.
Mitigation Measures:
 Configure the server to include appropriate Access-
Control-Allow-Origin headers.
 Use wildcard (*) for public APIs or specify trusted origins
for private APIs.
 Host the frontend and backend on the same domain or use
a reverse proxy to avoid cross-origin requests.

2. Impact: Preflight Request Overhead

  Description: For non-simple requests (e.g., PUT, DELETE, or
requests with custom headers), browsers send a preflight
request to check if the server allows the main request. This
adds latency to API calls.
 Example: An application making frequent PUT requests
may experience noticeable delays due to preflight
requests.
Mitigation Measures:
 Optimize server-side responses to allow preflight caching
using the Access-Control-Max-Age header:
 Use simple requests (GET or POST without custom
headers) where possible.

3. Impact: Overly Permissive Configuration

 Description: Misconfigured CORS policies (e.g., allowing all
origins with Access-Control-Allow-Origin: *) can expose
sensitive resources to malicious actors.
 Example: An API allowing all origins might be exploited by
an unauthorized website to steal user data.
Mitigation Measures:
 Define a specific set of trusted origins instead of using * for
Access-Control-Allow-Origin.
  Use Access-Control-Allow-Credentials: true carefully and
only with specified trusted origins.
 Audit and test CORS policies to ensure they meet security
requirements.

4. Impact: Increased Attack Surface

 Description: Misuse of CORS policies (e.g., excessive use of
wildcard origins) can open up new attack vectors like
Cross-Origin Resource Hijacking (CORH).
 Example: A wildcard origin combined with Access-Control-
Allow-Credentials: true can leak sensitive cookies.
Mitigation Measures:
 Avoid using Access-Control-Allow-Origin: * when Access-
Control-Allow-Credentials: true is enabled.
 Regularly review and test your CORS implementation for
security vulnerabilities.

5. Impact: Inconsistent Browser Behavior

 Description: Different browsers may handle CORS headers
differently, leading to unexpected behaviors.
 Example: An application working in Chrome might fail in
Safari due to stricter CORS enforcement.
 Mitigation Measures:
 Test the application in multiple browsers and devices.
 Follow standard practices and specifications for CORS
headers.

# What is HSTS
HSTS (HTTP Strict Transport Security) is a web security policy
mechanism that protects websites against certain types of
attacks, particularly man-in-the-middle (MITM) attacks and
protocol downgrade attacks. It enforces the use of HTTPS
(instead of HTTP) for all communications between a web server
and a browser.

How HSTS Works

When a website enables HSTS, it instructs the browser to:
1. Always communicate over HTTPS.
2. Reject any non-HTTPS connections, even if an attacker
attempts to downgrade the connection to HTTP.
3. Prevent users from bypassing HTTPS warnings (e.g., for
expired or invalid certificates).
This behavior is achieved by setting a specific HTTP header in
the server's response.
HSTS Header
The HSTS policy is activated via the Strict-Transport-Security
HTTP response header. Here’s an example:
Strict-Transport-Security: max-age=31536000;
includeSubDomains; preload
 max-age: Specifies how long (in seconds) the browser
should enforce the HSTS policy. For example, 31536000 is
one year.
 includeSubDomains: Ensures the policy applies to the
main domain and all its subdomains.
 preload: Indicates that the domain should be included in
the browser's HSTS preload list (discussed below).

Benefits of HSTS
1. Prevents Protocol Downgrade Attacks:
o An attacker could try to downgrade a secure HTTPS
connection to HTTP. HSTS ensures the browser won’t
accept this.
2. Defends Against SSL Strip Attacks:
 o SSL stripping involves intercepting HTTPS traffic and
converting it to HTTP. HSTS blocks this by requiring
HTTPS.
3. Enhances User Trust:
o Users are guaranteed a secure connection, reducing
the risk of sensitive data being intercepted.
4. Eliminates Mixed Content Warnings:
o HSTS ensures that all resources (e.g., scripts, images)
are loaded over HTTPS, avoiding mixed content
issues.

Risks and Challenges of HSTS

1. Lock-In Period:
o Once HSTS is set, users are locked into HTTPS for the
specified duration (max-age). Misconfigurations can
lead to accessibility issues.
2. Initial HTTP Request Vulnerability:
o If a user initially visits the site via HTTP, their first
request could be intercepted unless they’re already
on the HSTS preload list.
3. Preload List Commitment:
 o Adding a domain to the HSTS preload list is a
permanent decision; removing it can take significant
time and effort.
4. Invalid Certificates:
o If an HTTPS certificate expires or is misconfigured,
users cannot bypass the warning to access the site.

Best Practices for HSTS

1. Enable HTTPS First:
o Ensure your site is fully operational over HTTPS before
implementing HSTS.
2. Use a Conservative Max-Age Initially:
o Start with a lower value (e.g., max-age=86400 for one
day) during testing to avoid lock-in issues, and
increase it once you’re confident.
3. Enable includeSubDomains:
o Secure all subdomains unless you have specific ones
that cannot use HTTPS.
4. Test Thoroughly:
o Use tools like SSL Labs to verify your implementation.
5. Submit to the Preload List:
 o Once fully confident, consider submitting your
domain to the HSTS preload list for enhanced security.

LABS