Page History

Security tips

...

Disable devMode

The devMode is a very useful option during development time, allowing for deep introspection and debugging into you app.

However, in production it exposes your application to be back can expose your application presenting too many informations of on application's internals . Please always disable the devMode before or to evaluating risky parameter expressions. Please always disable devMode before deploying your application to a production environment. While it is disabled by default, your struts.xml might include a line setting it to true. The best way is to ensure the following setting is applied to our struts.xml for production deployment:

Reduce logging level

It's a good practice to reduce logging level from DEBUG to INFO or less. Framework's classes can produce a lot of logging entries which will pollute the log file. You can even set logging level to WARN for classes that belongs to the framework, see example Log4j2 configuration:

<?xml version="1.0" encoding="UTF-8"?>
<Configuration>
    <Appenders>
        <Console name="STDOUT" target="SYSTEM_OUT">
            <PatternLayout pattern="%d %-5p [%t] %C{2} (%F:%L) - %m%n"/>
        </Console>
    </Appenders>
    <Loggers>
        <Logger name="com.opensymphony.xwork2" level="warn"/>
        <Logger name="org.apache.struts2" level="warn"/>
        <Root level="info">
            <AppenderRef ref="STDOUT"/>
        </Root>
    </Loggers>
</Configuration>

Use UTF-8 encoding

Always use UTF-8 encoding when building an application with the Apache Struts 2, when using JSPs please add the following header to each JSP file

<%@ page contentType="text/html; charset=UTF-8" %>

Do not define setters when not needed

You should carefully design your actions without exposing anything via setters and getters, thus can leads to potential security vulnerabilities. Any action's setter can be used to set incoming untrusted user's value which can contain suspicious expression. Some Struts Results automatically populate params based on values in ValueStack (action in most cases is the root) which means incoming value will be evaluated as an expression during this process.

Do not use incoming values as an input for localisation logic

All TextProvider's getText(...) methods (e.g in ActionSupport) perform evaluation of parameters included in a message to properly localize the text. This means using incoming request parameters with getText(...) methods is potentially dangerous and should be avoided. See example below, assuming that an action implements getter and setter for property message, the below code allows inject an OGNL expression:

public String execute() throws Exception {
    setMessage(getText(getMessage()));
    return SUCCESS;
}

Never use value of incoming request parameter as part of your localisation logic.

Internal security mechanism

...

• struts.excludedClasses - comma-separated list of excluded classes
• struts.excludedPackageNamePatterns - patterns used to exclude packages based on RegEx - this option is slower than simple string comparison but it's more flexible
• struts.excludedPackageNames - comma-separated list of excluded packages, it is used with simple string comparison via startWith and equals

...

As from version 2.3.20 the framework provides two new interfaces which are used to accept / exclude param names and values - AcceptedPatternsChecker and ExcludedPatternsChecker with default implementations. These two interfaces are used by Parameters Interceptor and Cookie Interceptor to check if param can be accepted or must be excluded. If you were using excludeParams previously please compare patterns used by you with these provided by the framework in default implementation.

...