diff --git a/modules/core/distribution/src/assembly/bin.xml b/modules/core/distribution/src/assembly/bin.xml
index 0892cc94..a1851be3 100644
--- a/modules/core/distribution/src/assembly/bin.xml
+++ b/modules/core/distribution/src/assembly/bin.xml
@@ -763,6 +763,10 @@
             <source>src/repository/conf/security/Owasp.CsrfGuard.Carbon.properties</source>
             <outputDirectory>${pom.artifactId}-${pom.version}/repository/conf/security</outputDirectory>
         </file>
+        <file>
+            <source>src/repository/conf/security/Owasp.CsrfGuard.dashboard.properties</source>
+            <outputDirectory>${pom.artifactId}-${pom.version}/repository/conf/security</outputDirectory>
+        </file>
         <file>
             <source>../p2-profile-gen/target/wso2carbon-core-${carbon.kernel.version}/repository/conf/event-broker.xml
             </source>
diff --git a/modules/core/distribution/src/repository/conf/security/Owasp.CsrfGuard.dashboard.properties b/modules/core/distribution/src/repository/conf/security/Owasp.CsrfGuard.dashboard.properties
new file mode 100644
index 00000000..88257953
--- /dev/null
+++ b/modules/core/distribution/src/repository/conf/security/Owasp.CsrfGuard.dashboard.properties
@@ -0,0 +1,446 @@
+# The OWASP CSRFGuard Project, BSD License
+# Eric Sheridan (eric@infraredsecurity.com), Copyright (c) 2011
+# 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.
+
+# From: https://github.com/esheri3/OWASP-CSRFGuard/blob/master/csrfguard-test/src/main/webapp/WEB-INF/csrfguard.properties
+
+# 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 warfile as someApp.war, then %servletContext% will be /someApp
+# if there isnt 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
+
+# Logger
+#
+# The logger property (org.owasp.csrfguard.Logger) defines the qualified class name of
+# the object responsible for processing all log messages produced by CSRFGuard. The default
+# CSRFGuard logger is org.owasp.csrfguard.log.ConsoleLogger. This class logs all messages
+# to System.out which JavaEE application servers redirect to a vendor specific log file.
+# Developers can customize the logging behavior of CSRFGuard by implementing the
+# org.owasp.csrfguard.log.ILogger interface and setting the logger property to the new
+# logger's qualified class name. The following configuration snippet instructs OWASP CSRFGuard
+# to capture all log messages to the console:
+#
+# org.owasp.csrfguard.Logger=org.owasp.csrfguard.log.ConsoleLogger
+org.owasp.csrfguard.Logger=org.owasp.csrfguard.log.JavaLogger
+
+# 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 = false
+
+# 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
+
+# WSO2 : Since state-changing operations are not performed via HTTP GET,
+# disabling CSRF validation for GET method.
+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 proctected links that need tokens to be calculated.
+# 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
+
+# WSO2 : Considering overhead, necessity, as well as current unintended behaviour
+# of library after blocking a CSRF attack, disabling per-page tokens.
+org.owasp.csrfguard.TokenPerPage=false
+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. 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
+org.owasp.csrfguard.Ajax=true
+
+# 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
+
+# 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 evaulated 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.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.Invalidate=org.owasp.csrfguard.action.Invalidate
+
+# WSO2 : Disable redirecting user to an error page after blocking a CSRF attack
+#org.owasp.csrfguard.action.Redirect=org.owasp.csrfguard.action.Redirect
+#org.owasp.csrfguard.action.Redirect.Page=%servletContext%/error.html
+
+#org.owasp.csrfguard.action.RequestAttribute=org.owasp.csrfguard.action.RequestAttribute
+#org.owasp.csrfguard.action.RequestAttribute.AttributeName=Owasp_CsrfGuard_Exception_Key
+
+# WSO2 : Disabling token rotation after blocking a CSRF attack, since this behaviour
+# will break back navigation after blocking an attack.
+#org.owasp.csrfguard.action.Rotate=org.owasp.csrfguard.action.Rotate
+
+#org.owasp.csrfguard.action.SessionAttribute=org.owasp.csrfguard.action.SessionAttribute
+#org.owasp.csrfguard.action.SessionAttribute.AttributeName=Owasp_CsrfGuard_Exception_Key
+
+# WSO2 : Enable sending a 403 error after blocking a CSRF attack. Product teams
+# can add error page that handles 403 or “org.owasp.csrfguard.action.Error” to
+# display custom error pages.
+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.
+
+# 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
+
+# WSO2 : Since, CSRFGuard will send relevant token name as HTTP header
+# “X-” prefix was added to express that this is a non-standard header.
+org.owasp.csrfguard.TokenName=X-CSRF-Token
+
+# Session Key
+#
+# The session key property (org.owasp.csrfguard.SessionKey) defines the string literal used to save
+# and lookup the CSRFGuard token from the session. This value is used by the filter and the tag
+# libraries to retrieve and set the token value in the session. Developers can use this key to
+# programmatically lookup the token within their own code. The following configuration snippet sets
+# the session key to the value OWASP_CSRFTOKEN:
+#
+# org.owasp.csrfguard.SessionKey=OWASP_CSRFTOKEN
+org.owasp.csrfguard.SessionKey=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
+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
+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
+# WSO2 - Pseudo-random number generator provider should be configured based on
+# environment (SUN/IBMJCE)
+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
+
+# WSO2 : Disable printing configuration during start-up
+org.owasp.csrfguard.Config.Print = false
+
+###########################
+## Javascript servlet settings if not set in web.xml
+## https://www.owasp.org/index.php/CSRFGuard_3_Token_Injection
+###########################
+
+# leave this blank and blank in web.xml and it will read from META-INF/csrfguard.js from the jarfile
+# Denotes the location of the JavaScript template file that should be consumed and dynamically
+# augmented by the JavaScriptServlet class. The default value is WEB-INF/Owasp.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, maxage=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, maxage=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 = .*
+
+# 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 the HTTP method GET is unprotected, then this should likely be false
+
+# WSO2 : Disable JavaScript from injecting token value to HTTP GET based forms.
+# This prevents token leakage that could occur when sending token in URL.
+# State-changing actions should not be performed over HTTP GET
+org.owasp.csrfguard.JavascriptServlet.injectGetForms = false
+
+# if the token should be injected in the action in forms
+# note, if injectIntoForms is true, then this might not need to be true
+
+# WSO2 : Disable JavaScript from injecting token value to form action.
+# This prevents token leakage that could occur when sending token in URL.
+org.owasp.csrfguard.JavascriptServlet.injectFormAttributes = false
+
+
+# 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.
+
+# WSO2 : Disable JavaScript from injecting token value to “src” and “href”.
+# This prevents token leakage that could occur when sending token in URL.
+org.owasp.csrfguard.JavascriptServlet.injectIntoAttributes = false
+
+
+# WSO2 : Changing X-Request-With header text to avoid unnecessary information disclosure.
+org.owasp.csrfguard.JavascriptServlet.xRequestedWith = WSO2 CSRF Protection
+
+###########################
+## 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
+
+
+##########################
\ No newline at end of file