Field Filters 101: The Basics You Need to Know

Hello, Field Filters!

Data protection is a critical priority for any organization, especially when dealing with sensitive information like personal identifiable information (PII) and protected health information (PHI) data. Implementing robust protection mechanisms not only ensures compliance with regulations like the General Data Protection Regulation (GDPR) but also mitigates the risk of data breaches.

In Splunk, field filters (FF) provide a flexible way to control access to sensitive data at search time by redacting, replacing, or obfuscating sensitive fields in search results. This feature is particularly valuable for organizations looking to implement role-based access to data without altering the underlying source information. With field filters you will be able to:

Remove the field value from the search results.
Redact the value of a specific field by replacing it with a custom string such as <REDACTED>
Obfuscate the field value by replacing it with a hash using SHA-256 or SHA-512 (SHA-2 family) hash functions
Do not alter index data.

In this blog post, we will explore how field filters work, their core advantages, and typical scenarios for using them. By the end, you will understand how these filters can enhance the security of your Splunk data, ensuring that sensitive information remains protected, and know the implications of enabling this feature.

Enabling Field Filters

At the time of writing this post, the FF is a preview feature disabled by default, compatible with Splunk Enterprise 9.3 or later and Splunk Cloud 9.1.2312 or later.

Splunk Cloud

To enable FF in Splunk Cloud, you have to contact Splunk Support. If you have a support contract, open a new case through the Splunk Support Portal. If not, reach out directly to Splunk Customer Support.

Splunk Enterprise

To enable FF in Splunk Enterprise, you have to update the following conf files, and restart your Splunk Enterprise instance:

limits.conf – Search Head/s and Indexer/s

[search]
field_filters=true

web-features.conf – Search Head only

[feature:field_filters]
enable_field_filters_ui=true

After the change is applied, the field filters option will appear in the Settings menu. From there, you can create and manage FF using the UI, conf files or the Splunk Platform REST API endpoints:

Field Filters Types

You can use 2 general types of field filters:

Indexed: This method applies to all fields extracted by Splunk, whether they are created at index time or extracted at search time.

_raw: It will modify the raw event, which are the source events that appear in search results

We are going to skip the step-by-step tutorial on creating field filters, as it is available on the official documentation (Indexed vs _raw). Instead, we will compare how field filters work with both indexed and _raw methods, highlighting different options and their effects on the same set of events.

The subset of events simulates web access, and our goal is to protect the JSESSIONID field. Here is what the original events look like:

Indexed – Delete method

The delete method removes a specified field and its value from search results for most users, while keeping it visible to exempt roles. It is ideal for enforcing the highest level of privacy and compliance with legal or regulatory requirements.
In the example, the JSESSIONID extracted field will be removed from the results:

Indexed – String method

The string method replaces the field’s original value with a specified string, ensuring sensitive data remains private while still showing the field’s presence in search results. In this example, the JSESSIONID extracted field values will be updated to <REDACTED>:

Indexed – Hash method

The hash method generates a FIPS-compliant SHA-512 or SHA-256 hash of the field’s value and replaces the original data with this hash in the search results.

In this example, the JSESSIONID extracted field values will be hashed:

_raw – Sed (s) command

Uses a sed expression in the _raw field filter to replace strings matching a regular expression in search results.

For our example, the following sed expression was applied:

s/JSESSIONID=\S+/JSESSIONID=<REDACTED>/

_raw – Sed (y) command

Uses a sed expression in the _raw field filter to transliterate characters in search results. For example, y/abc/def/ replaces ‘a’ with ‘x’, ‘b’ with ‘y’, and ‘c’ with ‘z’. This expression changes the string aaabbc to xxyyz.

This method is not ideal for our scenario because it also replaces other characters in the event. However, we will create a Field Filter with it just to see the results. The following sed expression was applied:

y/SA/54/

Common Options

Both types of field filters share the following common options:

Description (optional): Provide a brief explanation or label for the filter.
Target index: The filter applies only to selected indexes.
Limit type: Restricts the filter by host, source, or source type to improve performance.
Exempt role: By default, the filter prevents all roles from accessing sensitive data. Add trusted roles to the exempt list so they can still access the data, and verify role inheritance before proceeding.
Configuration: Field filters can be created via UI, REST API or by updating the field_filters.conf file (in Splunk Enterprise environments).

⚠️ Implications and Restrictions

This is another example that shows there is not always an ideal solution. Despite their benefits, field filters also present a “dark side” with implications and restrictions which may make them unsuitable for your environment.

Splunk Enterprise Security, tstats, and other commands

Certain commands, such as mpreview, mstats, tstats, typeahead, walklex, and mcatalog, are disabled by default on any indexes that have field filters. These commands could reveal sensitive index details, creating a security risk if restricted users run them. Blocking these commands prevents potential exploitation by individuals who might try to bypass field filters.

There is a workaround to exclude highly trusted users and use the restricted commands when field filters are in use, so planning well before enabling and using this new feature is especially necessary.

Sequence of Search-Time

If you are unfamiliar with the sequence of search-time operations, I strongly recommend referring to the following link.

FF will be executed in the fourth position, after the Automatic Key-Value field extraction, and before the Field aliasing:

Which means that FF can be applied to Knowledge Objects that have been obtained in phase 1, 2, and 3. Operations performed after FF in the sequence that depend on field values might break.

For example, if a field filter replaces the “name” field with a placeholder string, and that field is used to calculate a new field, the new field may fail to calculate properly.

Roles

Field filters apply to all roles unless explicitly excluded. Be mindful of role inheritance: if the “Power” role is exempt from a field filter, then any role (e.g., “Analyst”) that inherits from “Power” is also exempt.

Summary Indexes

Reports run under the owner’s permissions by default. To protect sensitive data, set up summary indexes with a role that has field filters applied. For example, if the “analyst” role uses a field filter, you must also use the “analyst” role when creating the reports that feed the summary indexes. If not, scheduled reports can expose sensitive information.

The order matters!

The last FF in lexicographical order takes precedence and is applied.
For example, if a_replace_host replaces the value of the host field with the string REDACTED, and b_replace_host replaces the value of the field with the string REMOVED, and c_hash_host replaces the value of the field with a hash, then REDACTED is replaced with REMOVED, and REMOVED is hashed. The final field value that appears in the search results is a hash.

Do you want to know more implications?

For performance reasons, you should not exceed 5000 field filters.
Spaces, special symbols, and hyphens ( – ) are not allowed on the FF name.
Search Head/s and Indexer/s must run Splunk Enterprise version 9.3.0 or higher.
It does not support data model acceleration because of the tstats.
It cannot be used to protect sensitive fields in remote datasets using federated search.
FF will not be applied on searches that start with generating commands other than search: | inputcsv… | search…

…and now?

In conclusion, field filters offer a powerful way to enhance data privacy and regulatory compliance in Splunk. However, as we have explored, they also come with certain limitations and considerations. We encourage you to review the official Splunk documentation, experiment in a test environment, and carefully map out your organization’s roles, permissions, and use cases before implementing field filters.

Ready to take the next step? Dive deeper into Splunk’s official documentation, explore community discussions, or consult with our Splunk experts to ensure you are leveraging field filters effectively, and securely, without affecting your production environment.

Looking to expedite your success with Splunk? Click here to view our Professional Service offerings.

© Discovered Intelligence Inc., 2025. Unauthorized use and/or duplication of this material without express and written permission from this site’s owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to Discovered Intelligence, with appropriate and specific direction (i.e. a linked URL) to this original content.