Use the behaviors here to reduce the information your website shares with clients and malicious entities to reduce your exposure to threats.

Set up Allowed Methods

Recommended

This sub-rule is comprised of the various HTTP methods that should be allowed in requests for your Ion property. Since GET is the standard way end-user clients request content from your site or app, it's always enabled. The HEAD method is also enabled by default.

👍
For best performance and help with security, Akamai recommends that you leave the behaviors in the Allowed Methods sub-rule at their default settings.

POST

This is enabled by default to allow POST requests to your site or app. If you disable it, POST requests are denied and an HTTP 403 "Forbidden" response is returned.

📘
This needs to be enabled if you want to use the GraphQL sub-rule in the Offload Origin rule.

The Allow POST without Content-Length header option

Optionally change whether or not a POST request needs to include the Content-Type header.

Require the heading

At its default setting, Akamai edge servers will enforce the HTTP RFC standard that a POST request needs to contain a Content-Length header. The server returns an HTTP 411 "Length required" response if the header isn't present in a POST request.

📘
When set this way, an HTTP 411 is sent even when the POST request contains no body, which typically indicates that a Content-Length isn't required.

Don't require the heading

Click the slider to set it to Allow. By doing this, you're allowing POST calls that do not include the Content-Type header. Edge servers assume all POST requests have no Content-Length header body and they add this header with the value of "0" to the forward request—unless the request is using Chunked Transfer Encoding. These requests don't contain a Content-Length header.

OPTIONS

The HTTP OPTIONS method is used to describe communication options for your website or app's resources. Browsers typically send an HTTP OPTIONS request to find out:

which HTTP methods are supported, and
any other options that may be supported for your site or app resources, before sending the actual request.

HTTP OPTIONS requests let a browser see the parameters and requirements for specific resources and server capabilities without taking action on the resources, or actually requesting them.

By default, OPTIONS requests are allowed. This is the recommended setting.

PUT

The HTTP PUT method is used to update a resource. Typically, it replaces whatever exists at the target URL.

This is disabled by default, and requests that include a PUT request are answered with an HTTP 403 "Forbidden" response. This is the recommended setting to avoid any requests to modify your site or app resources.

📘
If you enable this, all content associated with an incoming PUT request is not cached.

DELETE

This is similar to the PUT sub-rule, but as its name implies, a request that includes it is looking to delete whatever exists at the target URL.

This is also disabled by default. Requests that include it will also be sent an HTTP 403. Leave it set this way to ensure that none of your site or app resources are deleted by an inadvertent or malicious DELETE request.

PATCH

This is also similar to the PUT sub-rule. In difference to a PUT, a PATCH request is looking to apply a partial modification to a resource, rather than replace it.

This is also disabled by default. Requests that include it are sent an HTTP 403. Leave it set this way so that none of your site or app resources are inadvertently or maliciously modified.

Set up Obfuscate debug info

Recommended

This sub-rule is here to ensure that back-end information isn't exposed to a request unless it includes the Pragma debug header. "Back-end information" can be anything relevant to your origin server. For example, this includes the code that runs on your origin server that receives and processes requests from clients and the database that persistently stores all of the data for your site or app.

The Cache Tag Visibility behavior determines how cache tags are returned on a request for the property. Cache tags can include back-end information, or at least allow a malicious user to decipher back-end information from them. To help with this, the Visibility of Cache Tags option is default set to Return Cache Tags only when Pragma header is sent. With it set this way, any cache tags that are included in the Edge-Cache-Tag header are only returned when you include the Pragma: akamai-x-get-cache-tags header in a request.

For more details on cache tag visibility see this behavior's topic in the Property Manager help.

Set up Obfuscate backend info

Recommended

This sub-rule is included as an additional measure to help protect against exposing back-end information to a request. Potentially sensitive back-end information will be kept out of the outgoing Response header if an additional "secret header" is included in the request.

It's default configured for you as a best practice. It includes these settings:

Criteria. This is set to Match All requests, with an "If" argument. The behaviors are applied if a request includes the X-Akamai-Debug header. This is the "secret header." You can bypass the application of the behaviors if the X-Akamai-Debug header in a request is set to true.
Modify Outgoing Response Header #1. This instance of the behavior is set up to remove the X-powered-by header field so it won't be exposed to a request in the Response header. The X-Powered-By response-header field can give specific information about your origin server, typically what kind of server it is. If this information is exposed, an attacker can use it to determine the type of origin server.
Modify Outgoing Response Header #2. This instance of the behavior is set up to remove the Server header field so it won't be exposed to a request in the Response header. The Server response-header field contains information about the software that your origin server uses to handle requests. If the specific version of software on your origin server is exposed, an attacker may be able to exploit known security holes.

👍
We recommend that you leave all settings in this behavior at their default when getting started with a new Ion property. But, you should regularly change the "If" argument in the Criteria to use a different, unique value for the secret header.

Add more Modify Outgoing Response Header behaviors

The two default instances of the Modify Outgoing Response Header behavior are included to help protect against known back-end information vulnerabilities. If you know of others you'd like to protect against, you can add more instances of this behavior to this sub-rule.

Hover over the top-right corner of either existing behavior and click Duplicate this behavior.

In the new instance of the behavior, change Custom Header Name to the Response header field you want to be removed from the outgoing Response header.

Set up HSTS

Optional

Use this to limit all access to your site or app to secure (HTTPS) requests. Once enabled requests that use HTTP will no longer be accepted. Before you enable it:

Make sure your site and any subdomains have been tested for HTTPS.
Make sure there are no situations where your domain needs to send data over HTTP.

Set up of this behavior isn't unique to Ion. See the Property Manager help topic for usage instructions.

Limitations on use

If you enable this behavior, you can't include the following behaviors in any rule that would be applied to the same request: