META-INF.csrfguard.properties Maven / Gradle / Ivy
Go to download
Show more of this group Show more artifacts with this name
Show all versions of csrfguard Show documentation
Show all versions of csrfguard Show documentation
OWASP CSRFGuard is a library that implements a variant of the synchronizer token pattern to mitigate the risk of Cross-Site Request Forgery (CSRF) attacks.
The newest version!
######################################################################################
# The OWASP CSRFGuard Project, BSD License
# Copyright (c) 2011, Eric Sheridan ([email protected])
# 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