Cross-Origin Resource Sharing (CORS)
Cross-origin resource sharing (CORS) is a browser security mechanism which enables controlled access to resources located outside of a given domain.
The diagram above shows that 2 clients are trying to access the web services of ‘My Application’ hosted in Port 8080. Client 1 uses the port 9090 to consume the RESTful web services whereas Client 2 uses the port 9091. In order to succeed this, CORS needs to be enabled in ‘My Application’ allowing ports 9090 and 9091 to access its web services.
What happens if CORS is not enabled in our application?
Our web application is running on port 8080 and we are trying to consume our RESTful APIs from the 9090 port. Under such situations, we will face the Cross-Origin Resource Sharing security issue on our web browsers.
There are 2 things which need to be done in order to handle to this issue:
RESTful web services should support the Cross-Origin Resource Sharing.
The RESTful web service application should allow accessing the APIs from the 9090 port.
GLOBAL CORS CONFIGURATION:
CORS configuration can be done globally by declaring it within Web MVC in the ‘BootcampApplication.java’ class. We need to override ‘addCorsMappings(CorsRegistry registry)’ method in the WebMvcConfigurer class.
The above code shows the @Bean configuration to set the CORS configuration support globally to our application.
In the above code,The registry.addMapping method returns a CorsRegistration object, which we can use for additional configuration. Since we want to allow all the request, we are passing “/**” as the parameter.
The allowedOrigins method lets us specify a comma-separated list of allowed origins (whitelisted origins). Since we want to disable CORS for all origins, we are passing “*” as the parameter. If you want to allow only a specific origin, you may provide the path of that origin as the parameter.
The allowedMethods method lets us specify a comma-separated list of HTTP methods that we want the web server to allow for cross-origin requests. We are providing “GET”, “POST”, “PUT”, “DELETE”, “HEAD” as the parameters.
Other than these, there are also allowedHeaders, exposedHeaders, maxAge and allowCredentials that we can use to set the response headers and customization options.
Spring Boot Actuator is used to monitor and manage the Spring Web Application with the help of secured HTTP endpoints.
In order to use the Actuator, we need to add the following dependency in the pom.xml file.
Now, we will handle the security or exposure of endpoints. We will do that using WebMvcEndpointHandlerMapping as can be observed using the code snippet: (This code needs to be added in the SecurityConfig.java file)
Working with Spring Boot Actuator:
By default, Actuator endpoints are enabled in Spring Boot, so no additional configuration is needed. However, you can customize the Actuator endpoints by adding properties to your application.yml file. For example, you can change the base path of Actuator endpoints or enable/disable specific endpoints.
Similarly, in order to enable a specific endpoint, use the following code in your application.yml file:
Once your Spring Boot application is running, you can access the Actuator endpoints via HTTP or JMX.
By default, Actuator endpoints are available at the /actuator base path. For example:
Health endpoint: ‘ http://localhost:8080/actuator/health’ - provides information about the health status of your application.
Metrics endpoint: ‘ http://localhost:8080/actuator/metrics’ - exposes various metrics about your application's performance, such as memory usage, request counts, response times, and more.
Info endpoint - ‘http://localhost:8080/actuator/info’ - provides general information about your application, such as the version, description, and any other custom details you want to expose.
You can access other endpoints based on your configuration or the default mapping.