csrfguard.properties

######################################################################################
# The OWASP CSRFGuard Project, BSD License
# Copyright (c) 2011, Eric Sheridan (eric@infraredsecurity.com)
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions are met:
#
#   1. Redistributions of source code must retain the above copyright notice,
#      this list of conditions and the following disclaimer.
#   2. Redistributions in binary form must reproduce the above copyright
#      notice, this list of conditions and the following disclaimer in the
#      documentation and/or other materials provided with the distribution.
#   3. Neither the name of OWASP nor the names of its contributors may be used
#      to endorse or promote products derived from this software without specific
#      prior written permission.
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
# (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
# LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
# ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
# SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
######################################################################################

##########################
## Common substitutions ##
##########################
# %servletContext% is the servlet context (e.g. the configured app prefix or war file name, or blank.
# e.g. if you deploy a default war file as someApp.war, then %servletContext% will be /someApp
# if there isn't a context it will be the empty string. So to use this in the configuration, use e.g. %servletContext%/something.html
# which will translate to e.g. /someApp/something.html

# Which configuration provider factory you want to use. The default is org.owasp.csrfguard.config.PropertiesConfigurationProviderFactory
# Another configuration provider has more features including config overlays: org.owasp.csrfguard.config.overlay.ConfigurationOverlayProviderFactory
# The default configuration provider is: org.owasp.csrfguard.config.overlay.ConfigurationAutodetectProviderFactory
# which will look for an overlay file, it is there, and the factory inside that file is set it will use it, otherwise will be PropertiesConfigurationProviderFactory
# it needs to implement org.owasp.csrfguard.config.ConfigurationProviderFactory
org.owasp.csrfguard.configuration.provider.factory = org.owasp.csrfguard.config.overlay.ConfigurationAutodetectProviderFactory

# If CSRFGuard filter is enabled
org.owasp.csrfguard.Enabled = true

# If csrf guard filter should check even if there is no session for the user
# Note: this changed around 2014/04, the default behavior used to be to 
# not check if there is no session. If you want the legacy behavior (if your app
# is not susceptible to CSRF if the user has no session), set this to false
org.owasp.csrfguard.ValidateWhenNoSessionExists = true

############################
## New Token Landing Page ##
############################
# The new token landing page property (org.owasp.csrfguard.NewTokenLandingPage) defines where
# to send a user if the token is being generated for the first time, and the use new token landing
# page boolean property (org.owasp.csrfguard.UseNewTokenLandingPage) determines if any redirect happens.
# UseNewTokenLandingPage defaults to false if NewTokenLandingPage is not specified, and to true
# if it is specified. If UseNewTokenLandingPage is set true then this request is generated
# using auto-posting forms and will only contain the CSRF prevention token parameter, if
# applicable. All query-string or form parameters sent with the original request will be
# discarded. If this property is not defined, CSRFGuard will instead auto-post the user to the
# original context and servlet path. The following configuration snippet instructs OWASP CSRFGuard to
# redirect the user to %servletContext%/index.html when the user visits a protected resource
# without having a corresponding CSRF token present in the HttpSession object:
#
# org.owasp.csrfguard.NewTokenLandingPage = %servletContext%/index.html

#######################
## Protected Methods ##
#######################
# The protected methods property (org.owasp.csrfguard.ProtectedMethods) defines a comma
# separated list of HTTP request methods that should be protected by CSRFGuard. The default
# list is an empty list which will cause all HTTP methods to be protected, thus preserving
# legacy behavior. This setting allows the user to inform CSRFGuard that only requests of the
# given types should be considered for protection. All HTTP methods not in the list will be
# considered safe (i.e. view only / unable to modify data). This should be used only when the
# user has concrete knowledge that all requests made via methods not in the list
# are safe (i.e. do not apply an action to any data) since it can actually introduce new
# security vulnerabilities. For example: the user thinks that all actionable requests are
# only available by POST requests when in fact some are available via GET requests. If the
# user has excluded GET requests from the list then they have introduced a vulnerability.
# The following configuration snippet instructs OWASP CSRFGuard to protect only the POST,
# PUT, and DELETE HTTP methods.
#
# org.owasp.csrfguard.ProtectedMethods = POST,PUT,DELETE
#
# or you can configure all to be protected, and specify which is unprotected. This is the preferred approach
#
# org.owasp.csrfguard.UnprotectedMethods = GET

############################
## Unique Per-Page Tokens ##
############################
# The unique token per-page property (org.owasp.csrfguard.TokenPerPage) is a boolean value that
# determines if CSRFGuard should make use of unique per-page (i.e. URI) prevention tokens as
# opposed to unique per-session prevention tokens. When a user requests a protected resource,
# CSRFGuard will determine if a page specific token has been previously generated. If a page
# specific token has not yet been previously generated, CSRFGuard will verify the request was
# submitted with the per-session token intact. After verifying the presence of the per-session token,
# CSRFGuard will create a page specific token that is required for all subsequent requests to the
# associated resource. The per-session CSRF token can only be used when requesting a resource for
# the first time. All subsequent requests must have the per-page token intact or the request will
# be treated as a CSRF attack. This behavior can be changed with the org.owasp.csrfguard.TokenPerPagePrecreate
# property. Enabling this property will make CSRFGuard calculate the per page token prior to a first
# visit.
#
# This option ONLY WORKS WITH JSTL token injection and is useful for preserving the validity of
# links if the user pushes the BACK button. There may be a performance impact when enabling this option
# if the JSP has a large number of protected links that need tokens to be calculated.
#
# Note: Pre-creating tokens is only available with the session bound token holder implementation,
# because in case for stateless or custom state implementations, client could would need
# to signal when it's ok to pre-create the tokens and this would affect the modularity/pluggability of the solution.
#
# Use of the unique token per page property is currently EXPERIMENTAL,
# but provides a significant amount of improved security. Consider the exposure of a CSRF token using
# the legacy unique per-session model. Exposure of this token facilitates the attacker's ability to
# carry out a CSRF attack against the victim's active session for any resource exposed by the web
# application. Now consider the exposure of a CSRF token using the experimental unique token per-page
# model. Exposure of this token would only allow the attacker to carry out a CSRF attack against the
# victim's active session for a small subset of resources exposed by the web application. Use of the
# unique token per-page property is a strong defense in depth strategy significantly reducing the
# impact of exposed CSRF prevention tokens. The following configuration snippet instructs OWASP
# CSRFGuard to utilize the unique token per-page model:
org.owasp.csrfguard.TokenPerPage = true
org.owasp.csrfguard.TokenPerPagePrecreate = false

####################
## Token Rotation ##
####################
# The rotate token property (org.owasp.csrfguard.Rotate) is a boolean value that determines if
# CSRFGuard should generate and utilize a new token after verifying the previous token. Rotation
# helps minimize the window of opportunity an attacker has to leverage the victim's stolen token
# in a targeted CSRF attack. However, this functionality generally causes navigation problems in
# most applications. Specifically, the 'Back' button in the browser will often cease to function
# properly. When a user hits the 'Back' button and interacts with the HTML, the browser may submit
# an old token causing CSRFGuard to incorrectly believe this request is a CSRF attack in progress
# (i.e. a 'false positive'). Users can prevent this scenario by preventing the caching of HTML pages
# containing FORM submissions using the cache-control header. However, this may also introduce
# performance problems as the browser will have to request HTML on a more frequent basis.
#
# Note: Rotation in case of AJAX requests is not supported currently because of possible race conditions.
# A Single Page Application can fire multiple simultaneous requests. If rotation is enabled for AJAX requests,
# the first request could trigger a token change before the validation of the same token within the second request,
# causing false-positive CSRF intrusion exceptions.
#
# The following configuration snippet enables token rotation:
#
# org.owasp.csrfguard.Rotate = true

#####################################
## Ajax and XMLHttpRequest Support ##
#####################################
# The Ajax property (org.owasp.csrfguard.Ajax) is a boolean value that indicates whether or not OWASP
# CSRFGuard should support the injection and verification of unique per-session prevention tokens for
# XMLHttpRequests. To leverage Ajax support, the user must not only set this property to true but must
# also reference the JavaScript DOM Manipulation code using a script element. This dynamic script will
# override the send method of the XMLHttpRequest object to ensure the submission of an X-Requested-With
# header name value pair coupled with the submission of a custom header name value pair for each request.
# The name of the custom header is the value of the token name property and the value of the header is
# always the unique per-session token value. This custom header is analogous to the HTTP parameter name
# value pairs submitted via traditional GET and POST requests. If the X-Requested-With header was sent
# in the HTTP request, then CSRFGuard will look for the presence and ensure the validity of the unique
# per-session token in the custom header name value pair. Note that verification of these headers takes
# precedence over verification of the CSRF token supplied as an HTTP parameter. More specifically,
# CSRFGuard does not verify the presence of the CSRF token if the Ajax support property is enabled and
# the corresponding X-Requested-With and custom headers are embedded within the request. The following
# configuration snippet instructs OWASP CSRFGuard to support Ajax requests by verifying the presence and
# correctness of the X-Requested-With and custom headers:
org.owasp.csrfguard.Ajax = true

#######################
## Protecting Pages  ##
#######################
# The default behavior of CSRFGuard is to protect all pages. Pages marked as unprotected will not be protected.
# If the Protect property is enabled, this behavior is reversed. Pages must be marked as protected to be protected.
# All other pages will not be protected. This is useful when the CsrfGuardFilter is aggressively mapped (ex: /*),
# but you only want to protect a few pages.
# org.owasp.csrfguard.Protect = true # TODO this should be renamed because it's confusing
#
# Defining pages to protect explicitly:
#
# org.owasp.csrfguard.protected.Protected = /protect.html
# org.owasp.csrfguard.protected.Test = /test.html
# org.owasp.csrfguard.protected.Forward = /forward.jsp

#######################
## Unprotected Pages ##
#######################
# The unprotected pages property (org.owasp.csrfguard.unprotected.*) defines a series of pages that
# should not be protected by CSRFGuard. Such configurations are useful when the CsrfGuardFilter is
# aggressively mapped (ex: /*). The syntax of the property name is org.owasp.csrfguard.unprotected.[PageName],
# where PageName is some arbitrary identifier that can be used to reference a resource. The syntax of
# defining the uri of unprotected pages is the same as the syntax used by the JavaEE container for uri mapping.
# Specifically, CSRFGuard will identify the first match (if any) between the requested uri and an unprotected
# page in order of declaration. Match criteria is as follows:
#
# Case 1: exact match between request uri and unprotected page
# Case 2: longest path prefix match, beginning / and ending /*
# Case 3: extension match, beginning *.
# Case 4: if the value starts with ^ and ends with $, it will be evaluated as a regex.
#   Note that before the regex is compiled, any common variables will be substituted (e.g. %servletContext%)
# Default: requested resource must be validated by CSRFGuard
#
# The following code snippet illustrates the four use cases over four examples. The first two examples
# (Tag and JavaScriptServlet) look for direct URI matches. The third example (Html) looks for all resources
# ending in a .html extension. The next example (Public) looks for all resources prefixed with the URI path /MySite/Public/*.
# The last example looks for resources that end in Public.do
#
# org.owasp.csrfguard.unprotected.Tag = %servletContext%/tag.jsp
# org.owasp.csrfguard.unprotected.JavaScriptServlet = %servletContext%/JavaScriptServlet
# org.owasp.csrfguard.unprotected.Html = *.html
# org.owasp.csrfguard.unprotected.Public = %servletContext%/Public/*
#
# Regex example starts with ^ and ends with $, and the %servletContext% is evaluated before the regex:
# org.owasp.csrfguard.unprotected.PublicServlet = ^%servletContext%/.*Public\.do$

# org.owasp.csrfguard.unprotected.Default = %servletContext%/
# org.owasp.csrfguard.unprotected.Upload = %servletContext%/upload.html
# org.owasp.csrfguard.unprotected.JavaScriptServlet = %servletContext%/JavaScriptServlet
# org.owasp.csrfguard.unprotected.Ajax = %servletContext%/ajax.html
# org.owasp.csrfguard.unprotected.Error = %servletContext%/error.html
# org.owasp.csrfguard.unprotected.Index = %servletContext%/index.html
# org.owasp.csrfguard.unprotected.JavaScript = %servletContext%/javascript.html
# org.owasp.csrfguard.unprotected.Tag = %servletContext%/tag.jsp
# org.owasp.csrfguard.unprotected.Redirect = %servletContext%/redirect.jsp
# org.owasp.csrfguard.unprotected.Forward = %servletContext%/forward.jsp
# org.owasp.csrfguard.unprotected.Session = %servletContext%/session.jsp

####################################
## Actions: Responding to Attacks ##
####################################
# The actions directive (org.owasp.csrfguard.action.*) gives the user the ability to specify one or more
# actions that should be invoked when a CSRF attack is detected. Every action must implement the
# org.owasp.csrfguard.action.IAction interface either directly or indirectly through the
# org.owasp.csrfguard.action.AbstractAction helper class. Many actions accept parameters that can be specified
# along with the action class declaration. These parameters are consumed at runtime and impact the behavior of
# the associated action.
#
# The syntax for defining and configuring CSRFGuard actions is relatively straight forward. Let us assume we wish
# to redirect the user to a default page when a CSRF attack is detected. A redirect action already exists within
# the CSRFGuard bundle and is available via the class name org.owasp.csrfguard.actions.Redirect. In order to enable
# this action, we capture the following declaration in the Owasp.CsrfGuard.properties file:
#
# syntax: org.owasp.csrfguard.action.[actionName] = [className]
# example: org.owasp.csrfguard.action.class.Redirect = org.owasp.csrfguard.actions.Redirect
#
# The aforementioned directive declares an action called "Redirect" (i.e. [actionName]) referencing the Java class
# "org.owasp.csrfguard.actions.Redirect" (i.e. [className]). Anytime a CSRF attack is detected, the Redirect action
# will be executed. You may be asking yourself, "but how do I specify where the user is redirected?"; this is where
# action parameters come into play. In order to specify the redirect location, we capture the following declaration
# in the Owasp.CsrfGuard.properties file:
#
# syntax: org.owasp.csrfguard.action.[actionName].[parameterName] = [parameterValue]
# example: org.owasp.csrfguard.action.Redirect.ErrorPage = %servletContext%/error.html
#
# The aforementioned directive declares an action parameter called "ErrorPage" (i.e. [parameterName]) with the value
# of "%servletContext%/error.html" (i.e. [parameterValue]) for the action "Redirect" (i.e. [actionName]). The
# Redirect action expects the "ErrorPage" parameter to be defined and will redirect the user to this location when
# an attack is detected.
# org.owasp.csrfguard.action.Empty = org.owasp.csrfguard.action.Empty
#
# org.owasp.csrfguard.action.Invalidate = org.owasp.csrfguard.action.Invalidate
#
# org.owasp.csrfguard.action.RequestAttribute = org.owasp.csrfguard.action.RequestAttribute
# org.owasp.csrfguard.action.RequestAttribute.AttributeName = Owasp_CsrfGuard_Exception_Key
#
# org.owasp.csrfguard.action.Error = org.owasp.csrfguard.action.Error
# org.owasp.csrfguard.action.Error.Code = 403
# org.owasp.csrfguard.action.Error.Message = Security violation.

org.owasp.csrfguard.action.Log = org.owasp.csrfguard.action.Log
org.owasp.csrfguard.action.Log.Message = Potential cross-site request forgery (CSRF) attack thwarted (user:%user%, ip:%remote_ip%, method:%request_method%, uri:%request_uri%, error:%exception_message%)

org.owasp.csrfguard.action.Redirect = org.owasp.csrfguard.action.Redirect
org.owasp.csrfguard.action.Redirect.Page = %servletContext%/error.html

org.owasp.csrfguard.action.Rotate = org.owasp.csrfguard.action.Rotate

# Extension modules can add their own actions. Please refer to their documentation to see what actions can be added.
# Extension provided actions should be added through a configuration overlay.
# org.owasp.csrfguard.action.SessionAttribute = org.owasp.csrfguard.action.SessionAttribute
# org.owasp.csrfguard.action.SessionAttribute.AttributeName = Owasp_CsrfGuard_Exception_Key

################
## Token Name ##
################
# The token name property (org.owasp.csrfguard.TokenName) defines the name of the HTTP parameter
# to contain the value of the OWASP CSRFGuard token for each request. The following configuration
# snippet sets the CSRFGuard token parameter name to the value OWASP-CSRFTOKEN:
org.owasp.csrfguard.TokenName = OWASP-CSRFTOKEN

##################
## Token Length ##
##################
# The token length property (org.owasp.csrfguard.TokenLength) defines the number of characters that
# should be found within the CSRFGuard token. Note that characters are delimited by dashes (-) in groups
# of four. For cosmetic reasons, users are encourage to ensure the token length is divisible by four.
# The following configuration snippet sets the token length property to 32 characters:
org.owasp.csrfguard.TokenLength = 32

####################################
## Pseudo-random Number Generator ##
####################################
# The pseudo-random number generator property (org.owasp.csrfguard.PRNG) defines what PRNG should be used
# to generate the OWASP CSRFGuard token. Always ensure this value references a cryptographically strong
# pseudo-random number generator algorithm. The following configuration snippet sets the pseudo-random number
# generator to SHA1PRNG:
org.owasp.csrfguard.PRNG = SHA1PRNG

#############################################
## Pseudo-random Number Generator Provider ##
#############################################
# The pseudo-random number generator provider property (org.owasp.csrfguard.PRNG.Provider) defines which
# provider's implementation of org.owasp.csrfguard.PRNG we should utilize. The following configuration
# snippet instructs the JVM to leverage SUN's implementation of the algorithm denoted by the
# org.owasp.csrfguard.PRNG property:

org.owasp.csrfguard.PRNG.Provider = SUN

# If not specifying the print config option in the web.xml, you can specify it here, to print the config
# on startup
org.owasp.csrfguard.Config.Print = true

##################################################################
## Javascript servlet settings if not set in web.xml            ##
## https://owasp.org/www-project-csrfguard                      ##
##################################################################

# This property denotes the location of the JavaScript template file that should be consumed and dynamically
# augmented by the JavaScriptServlet class.
# If it's left blank, and it's not configured in the web.xml either, it defaults to META-INF/csrfguard.js.
# Use of this property and the existence of the specified template file is required.
org.owasp.csrfguard.JavascriptServlet.sourceFile = 

# Boolean value that determines whether or not the dynamic JavaScript code should be strict
# with regards to what links it should inject the CSRF prevention token. With a value of true, 
# the JavaScript code will only place the token in links that point to the same exact domain 
# from which the HTML originated. With a value of false, the JavaScript code will place the 
# token in links that not only point to the same exact domain from which the HTML originated, 
# but sub-domains as well.
org.owasp.csrfguard.JavascriptServlet.domainStrict = true

# Allows the developer to specify the value of the Cache-Control header in the HTTP response 
# when serving the dynamic JavaScript file. The default value is private, max-age=28800.
# Caching of the dynamic JavaScript file is intended to minimize traffic and improve performance. 
# Note that the Cache-Control header is always set to "no-store" when either the "Rotate" 
# "TokenPerPage" options is set to true in Owasp.CsrfGuard.properties.
org.owasp.csrfguard.JavascriptServlet.cacheControl = private, max-age=28800

# Allows the developer to specify a regular expression describing the required value of the 
# Referer header. Any attempts to access the servlet with a Referer header that does not 
# match the captured expression is discarded. Inclusion of referer header checking is to 
# help minimize the risk of JavaScript Hijacking attacks that attempt to steal tokens from 
# the dynamically generated JavaScript. While the primary defenses against JavaScript 
# Hijacking attacks are implemented within the dynamic JavaScript itself, referer header 
# checking is implemented to achieve defense in depth.
org.owasp.csrfguard.JavascriptServlet.refererPattern = .*

# Used in conjunction with javascript servlet referer Match Domain, but this will make sure the referer of the
# javascript servlet matches the protocol of the request. If the referer Match Domain property is disabled,
# this property is not used
org.owasp.csrfguard.JavascriptServlet.refererMatchProtocol = true

# Similar to javascript servlet referer pattern, but this will make sure the referer of the 
# javascript servlet matches the domain of the request. If there is no referer (proxy strips it?)
# then it will not fail. Generally this is a good idea to be true.
org.owasp.csrfguard.JavascriptServlet.refererMatchDomain = true

# Boolean value that determines whether or not the dynamic JavaScript code should 
# inject the CSRF prevention token as a hidden field into HTML forms. The default 
# value is true. Developers are strongly discouraged from disabling this property 
# as most server-side state changing actions are triggered via a POST request.
org.owasp.csrfguard.JavascriptServlet.injectIntoForms = true

# If the token should be injected in GET forms (which will be on the URL).
# If this property is set to true, it will enable tokens injection into forms with GET method,
# even if the method was previously configured as unprotected.
org.owasp.csrfguard.JavascriptServlet.injectGetForms = true

# if the token should be injected in the action in forms
# note, if injectIntoForms is true, then this might not need to be true
org.owasp.csrfguard.JavascriptServlet.injectFormAttributes = true

# Boolean value that determines whether or not the dynamic JavaScript code should
# inject the CSRF prevention token in the query string of src and href attributes. 
# Injecting the CSRF prevention token in a URL resource increases its general risk 
# of exposure to unauthorized parties. However, most JavaEE web applications respond 
# in the exact same manner to HTTP requests and their associated parameters regardless 
# of the HTTP method. The risk associated with not protecting GET requests in this 
# situation is perceived greater than the risk of exposing the token in protected GET 
# requests. As a result, the default value of this attribute is set to true. Developers 
# that are confident their server-side state changing controllers will only respond to 
# POST requests (i.e. discarding GET requests) are strongly encouraged to disable this property.
org.owasp.csrfguard.JavascriptServlet.injectIntoAttributes = true

# Some applications might dynamically create new DOM elements (e.g. forms).
# This property enables an asynchronous MutationObserver or a DOMNodeInserted event listener if MutationObservers are not supported
# that is called when new elements are added to the DOM, then injects the CSRF tokens to it.
# Note: using event listeners can have a significant impact on performance, hence it defaults to false.
org.owasp.csrfguard.JavascriptServlet.injectIntoDynamicNodes = false

# This property defines the custom event name that will be fired manually by the client when a DOM element
# that requires CSRF tokens to be injected is modified or (e.g. form action changed) a new one is created.
# Since the default MutationObserver implementation is asynchronous, there might be corner-case race conditions
# between dynamically created and submitted forms and the time the MutationObserver is being invoked by the browser.
# These special cases are intended to be handled with this approach, because JavaScript events are executed synchronously.
# After a dynamic DOM element creation which requires token injection the integrator client has to manually fire an event
# with the same name provided below.
#
# Example client code, where 'updatedInjectableElement' is the dynamically created element added to the DOM:
#   const injectableNodeChangedEvent = new CustomEvent('InjectableNodeChanged', {detail: updatedInjectableElement});
#   window.dispatchEvent(injectableNodeChangedEvent);
#
# Note: this property does not default to a pre-defined value and is only considered,
# if 'org.owasp.csrfguard.JavascriptServlet.injectIntoDynamicNodes' is true.
# org.owasp.csrfguard.JavascriptServlet.dynamicNodeCreationEventName = InjectableNodeChanged

org.owasp.csrfguard.JavascriptServlet.xRequestedWith = OWASP CSRFGuard Project

# A comma separated list of file extensions can be added here to prevent the token from 
# being appended to them after pageload (which often causes a second copy of those static
# resources to be downloaded). ex: "js,css,gif,png,ico,jpg"
# org.owasp.csrfguard.JavascriptServlet.UnprotectedExtensions = js,css,gif,png,ico,jpg

####################################################################################################
## Config overlay settings if you have the provider above set to ConfigurationOverlayProvider     ##
## This CSRF config provider uses Internet2 Configuration Overlays (documented on Internet2 wiki) ##
## By default the configuration is read from the Owasp.CsrfGuard.properties                       ##
## (which should not be edited), and the Owasp.CsrfGuard.overlay.properties overlays              ##
## the base settings. See the Owasp.CsrfGuard.properties for the possible                         ##
## settings that can be applied to the Owasp.CsrfGuard.overlay.properties                         ##
####################################################################################################

# comma separated config files that override each other (files on the right override the left)
# each should start with file: or classpath:
# e.g. classpath:Owasp.CsrfGuard.properties, file:c:/temp/myFile.properties
org.owasp.csrfguard.configOverlay.hierarchy = classpath:Owasp.CsrfGuard.properties, classpath:Owasp.CsrfGuard.overlay.properties

# seconds between checking to see if the config files are updated
org.owasp.csrfguard.configOverlay.secondsBetweenUpdateChecks = 60

##########################
## Custom Token storage ##
##########################
# This parameter enables custom Token Holder implementations. It can be used when the backend has a stateless architecture.
# The implementation has to implement the org.owasp.csrfguard.token.storage.TokenHolder interface.
# The logic uses SPI to discover the implementation, so in the client module there should be a file called 'org.owasp.csrfguard.token.storage.TokenHolder' under the 'META-INF/services' directory that would contain
# the fully qualified class name of the custom implementation.
#
# Depends on the 'org.owasp.csrfguard.token.storage.LogicalSessionExtractor' property. If the dependency is not fulfilled, then this property will be disregarded.
# Defaults to 'org.owasp.csrfguard.token.storage.impl.InMemoryTokenHolder', which uses a ConcurrentHashMap to store the tokens.
# TODO review
# org.owasp.csrfguard.TokenHolder = org.owasp.csrfguard.token.storage.impl.InMemoryTokenHolder

# This parameter enables defining a custom logical session extractor. The logic must implement the 'org.owasp.csrfguard.token.storage.LogicalSessionExtractor' interface.
# TODO
# Defaults to 'org.owasp.csrfguard.session.ContainerSession', which uses the container's HttpSession in the background. The extensions module containing this logic has to be added as a Maven dependency to the project.
# If a custom implementation is required (e.g. stateless sessions with JWTs), the integration code should invoke the 'org.owasp.csrfguard.CsrfGuard.onSessionCreated' and 'org.owasp.csrfguard.CsrfGuard.onSessionDestroyed'
# The 'org.owasp.csrfguard.token.storage.LogicalSessionExtractor#getKey' method should return a unique identifier for a specific request (e.g. username from JWT token)
org.owasp.csrfguard.LogicalSessionExtractor = org.owasp.csrfguard.session.SessionTokenKeyExtractor

#################
## Concurrency ##
#################
# Defines for how many milliseconds the application should accept the master token instead of a newly generated page token.
#
# This parameter is aimed to solve the race condition when the 'org.owasp.csrfguard.TokenPerPage' option is enabled without 'org.owasp.csrfguard.TokenPerPagePrecreate'
# when multiple simultaneous AJAX ('org.owasp.csrfguard.Ajax') requests are fired by a Single Page Applications (SPA)
# before the initialization of the desired endpoint URIs. The first request against a specific endpoint URI is validated using the master token,
# then a new page token is generated for future calls, but in case of multiple simultaneously requests, the logic might not have time to assign
# the newly generated page token to the resource on the client side causing false positive intrusion exceptions.
#
# Note: This configuration does not (yet) enable the AJAX and Token Rotation combination. See the documentation for 'org.owasp.csrfguard.Rotate'
#
# Defaults to 2000 milliseconds (= 2 seconds).
org.owasp.csrfguard.PageTokenSynchronizationTolerance = 2000

# The current approach of the OWASP CSRFGuard relies on JavaScript logic for injecting CSRF tokens into HTML elements or XHR requests.
# Forcing synchronous loading of the AJAX requests has been disabled by default, since they were deprecated
# (see https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Synchronous_and_Asynchronous_Requests#synchronous_request)
# due to their negative impact on the user experience. For this reason, protecting resources that would load
# before or in parallel with the JavaScript logic (e.g. references IFrames or IMG tags) is not possible anymore.
# In most cases this should not be a problem, because usually GET requests should not facilitate state-changing operations.
# If case this last condition cannot be fulfilled (e.g. for legacy applications), backwards compatibility can be achieved by enabling the
# "forceSynchronousAjax" property below, until there is browser support for it.
#
# Defaults to False.
org.owasp.csrfguard.forceSynchronousAjax = false

# If there are properties prefixed with "org.owasp.csrfguard.bannedUserAgentProperty.", their values will be used to match against HTTP User-Agent request headers.
# In case of a match, the request will be discarded, and a 403 Forbidden response will be returned to the client.
# The purpose of this feature is to provide a way to prevent Internet Explorer users from accessing the web application.
# Internet Explorer is identified using the "msie" and "trident" strings.
org.owasp.csrfguard.bannedUserAgentProperty.InternetExplorer1 = msie
org.owasp.csrfguard.bannedUserAgentProperty.InternetExplorer2 = trident