CORS implementation

Looks great. Reading some of the KB articles, it seems to indicate that I need the ASM module to use CORS headers. Do you know if this is true? (I have a pending ticket, but, unfortunately, this question is actively holding me up.

EDIT: ASM module is not required. This can be done via iRule. F5 support pointed me specifically to this page.

Hello,

I have solved a issue applying this irule.

Thank you

Very useful code, and you can add that it solves an issue with the cookie persistence : when a browser sends a pre-flight request, by definition in RFC2616 it doesn't send any cookie with the OPTIONS method. So when the bigip receives the OPTIONS request, without cookie, it considers it as a new request, round robin the pool member, and in the http_reply the bigip includes a set_cookie ... The browser receives the set_cookie, thus drops the one it already had ... And voilà you lost your session :(

So with this iRule, the bigip doesn't send the pre-flight request to the pool member, and doesn't send a set_cookie back => your browser will keep the session cookie

Maybe F5 should consider a feature to not reply with a set_cookie to an OPTIONS request ?

@Cyril, your comment about new request pooling messing with cookies hadn't occurred to me - very good point!

I didn't challenge the F5 support yet to know if this whole "disable set-cookie when replying to an OPTIONS request" is something that can be done out of the box (and what firmware ?) or if using an iRule is mandatory ...

After hours of struggling with syntax errors, support helped identify a correction I'll pass along.

1) I wasn't able to define the class inside of the iRule and had to create a Data Group object (type: string) that contained the allowed origins as String with a blank value.

If the though of using a GUI brings a tear to your eye, here's the CLI:

ltm data-group internal DG-CORS-ALLOWED-ORIGINS {
    records {
        .authorizeddomain.com { }
        localhost:3456 { }
    }
    type string
}

2) The syntax in OP's iRule required the addition of more brackets.

This lines gives me an error: /Common/IRULE-CORS:10: error: [parse error: PARSE syntax 228 {syntax error in expression " class match [HTTP::header Origin] ends_with allowed_origins...": variable references require preceding $}][{ class match [HTTP::header Origin] ends_with allowed_origins }]

if { class match [HTTP::header Origin] ends_with DG-CORS-ALLOWED-ORIGINS }

Enclosed class in brackets and received no syntax errors:

if { [class match [HTTP::header Origin] ends_with DG-CORS-ALLOWED-ORIGINS] }

This was tested in LTM 11.6.0

Code snippet updated to include additional square brackets in the

class match

I have not noticed any further comment about responses to set-cookie, so I thought I would respond. Section 7.1.5 Cross-Origin Request with Preflight of the latest CORS specification (https://www.w3.org/TR/cors/) states the client shall make the OPTIONS request with the "block cookie" flag set. For newer HTTP clients this means any response to an OPTIONS request with Origin header must ignore all set-cookie headers. But as others on this thread have noted, not all HTTP clients are up to date on handling set-cookie for a preflight response. Therefore, to err on the side of caution, I too strongly recommend handling the CORS preflight requests as close to the edge of the network as possible.

To piggyback on security settings I've also taken to add the header Content-Security-Policy: frame-ancestors 'self' '$cors_origin'; when a Origin header was found otherwise respond with the header Content-Security-Policy: frame-ancestors 'self';

@Kevin_Dyer note that the reference you cite for latest CORS specification is actually significantly out-of-date.

The responsibility for CORS was taken over by WHATWG, as part of the fetch spec (https://fetch.spec.whatwg.org/). The examples aren't great, but fetch now does allow (in theory) some enhancements, such as allowing an asterisk as the value for the

Access-Control-Allow-Headers

Access-Control-Allow-Methods

Access-Control-Expose-Headers

Hello, I would like to Apply this Irules, but i have an error when I create this.

01070151:3: Rule [/Common/IR_CROSS_DOMAIN_XXXXX.XXX] error: /Common/IR_CROSS_DOMAIN_XXXXX.XXX:2: error: [command is not valid in the current scope][class allowed_origins { ".XXXXX.XXX" }]

Anyone have a idea ?

Version : BIG-IP 11.5.3 Build 1.0.167 Hotfix HF1