Configuration Options

Configuring the rust module in Fastly is done via the Compute@Edge Dictionary.

Required Configurations

Optional Configurations

Auto deploying the configurations

We have created the pxconfig.sh script to be used to populate the configurations in the Dictionary automatically. Following is an example to populate the required configurations only:

1
Required options:
2
-s, --service-id=SERVICE_ID       specify a service to deploy the dictionary
3
-v, --version=VER                 specify a service version
4
-a, --appid=APPID                 specify an appid
5
-c, --cookie_secret=SECRET        specify a cookie_secret
6
-t, --auth_token=TOKEN            specify an auth_token

Enforcer Configuration

To manually add or update the configurations, you can use Config Stores in the Fastly Web UI. The configurations should be added to the Config Store named PXConfig as key-value pairs.

Configuration types:

• String: A sequence of characters, without quotes. Example: my_string
• Boolean: A true or false value. Example: true or false
• Number: A numeric value. Example: 100
• List: A comma-separated list of values without quotes. Example: value1, value2
• Regex List: A comma-separated list of regular expressions without quotes. Example: ^/graphql$, ^/api/graphql$

GraphQL Configurations

px_graphql_enabled

Whether the enforcer should attempt to parse and report information about GraphQL operations on incoming requests.

Default: false

1
    "px_graphql_enabled": true

px_graphql_routes

A comma-separated list of regex routes that will be checked for sensitive GraphQL operations. If a request’s route matches any of the regexes in this list, it will be checked for sensitive GraphQL operations as configured in px_sensitive_graphql_operation_types and px_sensitive_graphql_operation_names. If the request contains a sensitive operation, it will trigger a server call to HUMAN servers every time that operation is performed, regardless of cookie state.

Default: ^/graphql$

1
    "px_graphql_routes": ^/graphql$, ^/api/graphql$

px_sensitive_graphql_operation_types

A comma-separated list of operation types (query, mutation, or subscription) that should be considered sensitive. If one or more GraphQL operations on an HTTP request is found to have a type matching the list configured here, it will trigger a Risk API call even if the request contains a valid, unexpired cookie.

Default: ""

1
    "px_sensitive_graphql_operation_types": mutation, subscription

px_sensitive_graphql_operation_names

A comma-separated list of operation names that should be considered sensitive. If one or more GraphQL operations on an HTTP request is found to have a name matching the list configured here, it will trigger a Risk API call even if the request contains a valid, unexpired cookie.

Default: ""

1
    "px_sensitive_graphql_operation_names": SensitiveOperation1, SensitiveOperation2

CORS support

px_cors_support_enabled

CORS (Cross-Origin Resource Sharing) is a mechanism that enables the server to indicate when a request contains cross-origin resources. It does so by adding special HTTP headers to the request, which permits the browser to load these resources. Without these headers, the browser may block requests to these resources for security reasons.

In most cases, CORS employs a two-stage procedure with a preliminary “preflight” request followed by the actual request. The preflight request checks if the actual request will be responded to. To learn more about different request types, see these examples.

In the Enforcer, CORS behavior must be configured to address both simple requests (without preflight) and more complex ones (with preflight). Enabling CORS support via this configuration will have the following effects:

• It will automatically add the following default CORS response headers to block responses resulting from CORS requests.

Access-Control-Allow-Origin: <ORIGIN_REQUEST_HEADER_VALUE>
Access-Control-Allow-Credentials: true

Default: false

1
    "px_cors_support_enabled": true

Cors custom block response headers callback function

If the default CORS response headers are not sufficient, it is possible to completely customize the headers that should be added to all block responses resulting from CORS requests. If a callback function is defined, the default headers will not be added; only those headers specified in the returned vector will be added to the block response.

Functions definitions:

1
pub type PXCorsCustomBlockResponseHeadersFn =
2
    fn(req: &Request, conf: &PXConfig) -> Vec<(String, String)>;
3
4
pub fn set_cors_create_custom_block_response_headers_fn(
5
    &mut self,
6
    f: PXCorsCustomBlockResponseHeadersFn,
7
)

Default: None

1
// callback function to create custom CORS headers for block responses
2
fn cors_block_response_headers(req: &Request, _conf: &PXConfig) -> Vec<(String, String)> {
3
    vec![
4
        (
5
            "Access-Control-Allow-Origin".to_string(),
6
            req.get_header_str("Origin").unwrap_or_default().to_string(),
7
        ),
8
        (
9
            "Access-Control-Allow-Credentials".to_string(),
10
            "true".to_string(),
11
        ),
12
        (
13
            "Access-Control-Allow-Methods".to_string(),
14
            "GET, POST, OPTIONS".to_string(),
15
        ),
16
        (
17
            "Access-Control-Allow-Headers".to_string(),
18
            "Content-Type, Authorization".to_string(),
19
        ),
20
    ]
21
}
22
23
...
24
25
px.set_cors_create_custom_block_response_headers_fn(cors_block_response_headers);

px_cors_preflight_request_filter_enabled

This configuration disables enforcement for CORS preflight requests. When this configuration is set to true, CORS preflight requests will be filtered from the enforcer flow. That is, they will pass through the enforcer flow without triggering detection or block responses.

Default: false

1
    "px_cors_preflight_request_filter_enabled": "true"

Cors custom preflight handler

If a more customized approach is needed for handling CORS preflight requests, this custom function can be set to define the desired behavior. The custom function should receive the original HTTP request and return an object representing the HTTP response to be returned. If None is returned from the function, the Enforcer will continue processing the preflight request.

Functions definitions:

1
pub type PXCorsCustomPreflightHandlerFn =
2
    fn(req: &Request, conf: &PXConfig) -> Option<Response>;
3
pub fn set_cors_custom_preflight_handler_fn(
4
    &mut self, f: PXCorsCustomPreflightHandlerFn);

Default: None

1
// callback function to handle CORS preflight requests
2
fn cors_preflight_handler(req: &Request, _conf: &PXConfig) -> Option<Response> {
3
    if !req.get_method_str().eq_ignore_ascii_case("OPTIONS")
4
        || !req.contains_header("Origin")
5
        || !req.contains_header("Access-Control-Request-Method")
6
    {
7
        return None;
8
    }
9
10
    let mut response_headers = HashMap::new();
11
    response_headers.insert(
12
        "Access-Control-Allow-Origin",
13
        req.get_header_str("Origin").unwrap_or_default(),
14
    );
15
    response_headers.insert(
16
        "Access-Control-Allow-Methods",
17
        req.get_header_str("Access-Control-Request-Method")
18
            .unwrap_or_default(),
19
    );
20
    response_headers.insert(
21
        "Access-Control-Allow-Headers",
22
        req.get_header_str("Access-Control-Request-Headers")
23
            .unwrap_or_default(),
24
    );
25
    response_headers.insert("Access-Control-Allow-Credentials", "true");
26
    response_headers.insert("Access-Control-Max-Age", "86400");
27
28
    let mut response = Response::new();
29
    response.set_status(fastly::http::StatusCode::NO_CONTENT);
30
    for (name, value) in response_headers {
31
        response.set_header(name, value);
32
    }
33
34
    Some(response)
35
}