CODEWITHSUNDEEP
javahttp-headersapache-tomee
GangBanga
GangBanga

Reputation: 11

Disabling OPTIONS http request in tomee

I'm looking for a way to disable http Options request in my java EE app which security audit said we should disable. I'm testing it with curl command:

curl -i --request-target "*" -X OPTIONS http://localhost:8080/something/

and I always get response:

HTTP/1.1 200 Allow: GET, HEAD, POST, PUT, DELETE, OPTIONS Content-Length: 0 Date: Tue, 01 Oct 2024 12:21:46 GMT Server: Apache TomEE

No matter what I do, the same methods are always allowed

I tried removing it with custom headers filter like so:

public class OptionsMethodFilter implements Filter {

    @Override
    public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException, ServletException {
        HttpServletRequest request = (HttpServletRequest) req;
        HttpServletResponse response = (HttpServletResponse) res;

        if ("OPTIONS".equalsIgnoreCase(request.getMethod())) {
            // Handle the OPTIONS request explicitly and prevent default behavior
            response.setHeader("Allow", "GET, POST, PUT, DELETE");
            response.setStatus(HttpServletResponse.SC_OK);
        } else {
            // Continue with the regular request handling
            chain.doFilter(req, res);
        }
    }

and I already have security-constraint configured in my web.xml from before

    <security-constraint>
        <display-name>Locked Resources</display-name>
        <web-resource-collection>
            <web-resource-name>securityconstraint</web-resource-name>
            <url-pattern>/*</url-pattern>
            <http-method>GET</http-method>
            <http-method>PUT</http-method>
            <http-method>DELETE</http-method>
            <http-method>HEAD</http-method>
            <http-method>TRACE</http-method>
            <http-method>OPTIONS</http-method>
            <http-method>POST</http-method>
        </web-resource-collection>
        <auth-constraint>
            <description/>
            <role-name>authusr</role-name>
        </auth-constraint>
    </security-constraint>

Upvotes: 1

Views: 49

Answers (1)

Spyros K
Spyros K

Reputation: 2605

Many things would qualify as 'disable'. Your approach answers to an OPTIONS request by notifying that only GET, POST, PUT, DELETE are allowed. Although OPTIONS is not returned in the list of allowed HTTP verbs, one could argue that OPTIONS is implicitly and de-facto allowed since the server send an answer to an OPTION request.

A step further would be to make OPTIONS completely forbidden. The following approach is an update to the filter approach you provide. The filter returns a 403 - Forbidden status instead of providing a response to OPTIONS and then stops any other filter from being executed. This way the server will return a 403 forbidden whenever it gets an OPTIONS request.

Another part that needs to be clarified is that your request with curl gets a different response than expected. You could debug the server to make sure that the filter you created is called.Then it would be a matter of correct configuration to make the server apply the filter created.

@Override
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) 
        throws IOException, ServletException {

    final HttpServletRequest httpRequest = (HttpServletRequest) request;
    final HttpServletResponse httpResponse = (HttpServletResponse) response;

    // Check if the method is OPTIONS and send 403 Forbidden
    if ("OPTIONS".equalsIgnoreCase(httpRequest.getMethod())) {
       // Send 403 Forbidden
        httpResponse.setStatus(HttpServletResponse.SC_FORBIDDEN);
        //Stop any further processing of the request 
        return;
    }

    // Continue with the next filter in the chain
    chain.doFilter(request, response);
}

Upvotes: 0

Related Questions