Welcome to the second lesson of the "Web Resource Integrity and Secure Configuration in Java Web Applications" course! In this lesson, we'll explore Cross-Origin Resource Sharing (CORS), a crucial aspect of web security. CORS is a mechanism that allows or restricts resources on a web page to be requested from another domain. Properly configuring CORS is essential to prevent unauthorized access to your web applications. In this lesson, we will focus on how to understand and securely configure CORS in Java web frameworks such as Spring Boot. 🌐

Previously, we covered how to detect data integrity failures through SRI and discussed how to avoid them by understanding their roots in improper resource verification. This included hash generation, integrity attribute implementation, and automated SRI injection as ways to prevent unauthorized resource modifications.

However, even with robust resource integrity controls in place, data integrity can still be compromised through cross-origin attacks. For example, if a user is authenticated to your banking application, a malicious site they visit at the same time could make requests to your API and potentially modify or extract sensitive data by leveraging the user's authenticated session.

This is where CORS becomes essential. While SRI mechanisms verify resource integrity, CORS controls which external origins are permitted to interact with your application in the first place, addressing a critical vector for potential data integrity breaches.

CORS is a security feature implemented by web browsers to control how resources are shared between different origins. An "origin" is defined by the combination of a URL's protocol, domain, and port. Without CORS, a web application could freely request resources from any domain, which could lead to security vulnerabilities. Improper CORS configuration can expose sensitive data to unauthorized domains, making it crucial to understand and implement CORS correctly.

Understanding CORS Enforcement: CORS headers (like Access-Control-Allow-Origin) are instructions to browsers on how to handle cross-origin requests. The browser enforces these policies—if a server returns permissive CORS headers, the browser will allow the cross-origin request. However, server-side Origin validation (checking the header in your application code) provides defense-in-depth for API-to-API calls and can block requests before they reach your application logic, even if a browser isn't involved.

Before making certain cross-origin requests, browsers automatically send a preflight request to check if the CORS policy allows the actual request. This preflight is an HTTP OPTIONS request that includes headers describing the intended request.

When does a browser send a preflight request?

Browsers send preflight requests for "non-simple" requests, which include:

• Requests using methods other than GET, HEAD, or POST
• POST requests with content types other than application/x-www-form-urlencoded, multipart/form-data, or text/plain
• Requests with custom headers (like Authorization)

Example preflight flow:

1. Browser prepares to make POST /api/data with Authorization header
2. Browser first sends: OPTIONS /api/data with headers:
   • Origin: https://example.com
   • Access-Control-Request-Method: POST
   • Access-Control-Request-Headers: Authorization
3. Server responds with CORS headers indicating if the request is allowed
4. If allowed, browser proceeds with the actual POST request

To understand the importance of secure CORS configuration, let's look at how a poorly configured CORS can be exploited. Imagine a scenario in which a web application allows requests from any origin. An attacker could exploit this by creating a malicious script that accesses sensitive data from the application.

Important Note: CORS is a browser-enforced security mechanism. The curl command below demonstrates what CORS headers the server returns, but it does not actually test CORS enforcement, since curl is not a browser and will succeed regardless of CORS configuration. The real attack scenario occurs when a malicious website makes requests from a victim's browser, leveraging the user's authenticated session. The browser enforces CORS policies based on the headers returned by the server.

In this example, the curl command shows what CORS headers the server would return. If the application is improperly configured to allow any origin, the server will include permissive CORS headers in its response. However, the actual security risk occurs when a malicious website makes requests from a victim's browser—the browser will see these permissive headers and allow the malicious site to access sensitive data from the vulnerable application, potentially exposing it to the attacker.

Now, let's configure CORS securely in a Java web application using the Spring Boot framework. Spring Boot provides flexible ways to manage CORS settings, allowing you to specify which origins, methods, and headers are permitted.

In Java with Spring Boot, CORS configuration can be initiated using either annotations or configuration classes. For more granular and secure control, we will use a configuration class.

We specify the allowed origins as a list of trusted domains. This ensures that only requests from these domains are permitted to access your resources.

Note:
For production deployments, only include trusted domains in the ALLOWED_ORIGINS array. During local development and testing, you may need to add "http://localhost" and/or "http://127.0.0.1:3000" to allow your frontend (running locally) to interact with your API. Be sure to remove or restrict these local origins before deploying to production to avoid exposing your API to unintended sources.

Example for development:

To enable and configure CORS in Spring Boot, create a configuration class that implements WebMvcConfigurer. This class will define which origins, methods, and headers are allowed.

In this configuration:

• addMapping("/api/**") specifies which endpoints the CORS settings apply to.
• .allowedOrigins(origins) restricts access to the trusted domains specified in the array.
• .allowedMethods("GET", "POST") limits the allowed HTTP methods.
• .allowedHeaders("Content-Type", "Authorization") specifies which headers are permitted.
• .allowCredentials(true) allows cookies and credentials to be sent with requests.

By configuring CORS in this way, you ensure that only requests from trusted origins are allowed, with specific methods and headers permitted.

When configuring CORS, it's important to follow best practices to avoid common pitfalls:

• Limit Origins: Only allow trusted domains to access your resources.
• Restrict Methods: Specify only the HTTP methods that are necessary for your application.
• Control Headers: Define which headers are allowed to prevent unauthorized data access.
• Use Credentials Wisely: Enable credentials only if necessary and ensure the secure handling of cookies.

By adhering to these best practices, you can significantly reduce the risk of unauthorized access to your web application.

In this lesson, we explored the importance of CORS in web security and learned how to configure it securely in Java web applications using Spring Boot. We examined both offensive and defensive examples to understand the potential risks and how to mitigate them. As you move forward, you'll have the opportunity to practice these concepts in upcoming exercises. Keep these best practices in mind as you continue to build secure web applications. Happy coding! 🚀