XML Developer's Guide

```xml Bad theme={null} ... ``` ```xml Fix theme={null} ... ```

Having robust documentation just makes life easier. That applies to XSD’s as well. Each one should include a description of its intended use, and perhaps versioning.

This rule raises an issue when there’s neither a comment before the \ tag, nor \\...\\ just inside the \ element.

```xml Bad theme={null} ... ``` ```xml Fix theme={null} <-- This schema is intended... --> ... ```

Shared naming conventions allow teams to collaborate efficiently. This rule checks that all attribute names match a provided regular expression.

```xml Bad theme={null} ... ``` ```xml Fix theme={null} ... ```

EJB interceptors provide a way to define code that can be executed before and after a method call. They are typically used for logging, testing, auditing or security purposes.

Interceptor methods can be applied or bound at three levels:

The default interceptor is called for each bean as part of the deployment and can only be applied through an XML file.
The class-level interceptor is invoked for each method of the bean. The class-level interceptor can be applied both through an annotation and through an XML file.
The method-level interceptor is invoked for a specific method of the bean. The method-level interceptor can be applied both through an annotation and through an XML file.

If you want to declare these methods in an XML file, you must declare them in a file named ejb-jar.xml. Otherwise, they may not be applied or used as intended.

```xml Bad theme={null}

com.myco.ImportantInterceptor

``` ```xml Fix theme={null}

com.myco.ImportantInterceptor

```

Filters are used to intercept requests and responses from a server and allow developers to manipulate them. When a filter is declared, but the corresponding filter assignment is inadvertently not, then the code is vulnerable to security problems or business logic instability.

If a filter is defined in the web application descriptor file web.xml but is not used in a "filter mapping", this is an indication that it may have been forgotten.

```xml Bad theme={null}

ValidationFilter

com.myco.servlet.ValidationFilter

``` ```xml Fix theme={null}

ValidationFilter

com.myco.servlet.ValidationFilter

ValidationFilter

```

rameworks usually have options to make debugging easier for developers. Although these features are useful during development, they should never be enabled for applications deployed in production.

Activating a development feature in production can have an important range of consequences depending on its use:

Technical information leak; generally by disclosing verbose logging information to the application’s user.
Arbitrary code execution; generally with a parameter that will allow the remote debugging or profiling of the application.

In all cases, the attack surface of an affected application is increased. In some cases, such features can also make the exploitation of other unrelated vulnerabilities easier.

```xml Bad theme={null} ``` ```xml Fix theme={null} ```

Having a \`nillable element in a schema means that element must always be present, whether or not you have data for it. That means that the resulting XML transmissions will be larger than they need to be. On the other hand, minOccurs="0" communicates the same "there is no value" message, with smaller XML messages. For that reason, minOccurs="0" is almost always preferred over nillable="true". The one case were nillable="true" is valuable is in the case of an array element, where you may have the need to set a placeholder.

This rule raises an issue when nillable="true" is used on an element were maxOccurs\` is 1.

```xml Bad theme={null} ``` ```xml Fix theme={null} ```

In Struts, form validation is used to validate the data the application’s clients provide as part of a form submission to the server. Configuring two different form validations with the same name leads to unexpected behaviors.

When faced with multiple form validations with the same name, Struts will arbitrarily choose one and apply it while discarding the others.

```xml Bad theme={null} ``` ```xml Fix theme={null} ```

\`xs:any and xs:anyAttribute are wildcards; they allow the XML document author to use any element or attribute. By specifying nameSpaces for them, you can restrict what’s used to elements in the specified name spaces. By default, what’s used for xs:any and xs:anyAttribute will be validated in a strict manner (processContents="strict"). That is, validation will fail if the element used isn’t recognized. That makes sense if you’ve provided a namespace, but not if you haven’t. Conversely, processContents="lax" allows unrecognized elements to pass validation even if they’re not recognized. That makes sense if no namespace has been specified, but not if one has been specified.

This rule raises an issue when strict processing is used (either explicitly or implicitly) when no namespace is provided, and conversely when lax\` processing is used with a namespace.

```xml Bad theme={null} ToDo ``` ```xml Fix theme={null} ToDo ```

Certain prefixes are widely recognized and expected to correspond to specific namespaces. For instance, most users will expect "xs" to correspond to "[http://www.w3.org/2001/XMLSchema](http://www.w3.org/2001/XMLSchema)". If you subvert that expected correspondence, you run the risk of severely confusing the users of your XSD.

```xml Bad theme={null}

The use of a targetNamespace in an XSD means that all the elements described in the XSD are restricted to that namespace, rather than landing in the global namespace. This provides clarity, and makes the schema easier to use in concert with other schemas that might define elements with the same names.

```xml Bad theme={null} ... ``` ```xml Fix theme={null} ... ```

\`ID and IDREF are constructs inherited from DTDs, and they suffer from painful drawbacks, mainly:

IDs are too widely scoped: an ID must be unique in the XML document. This means that if an XML document contains \ elements and \ elements, both with a "name" attribute of type="xs:ID", then two people can’t have the same name. Neither can two dogs, or a person and a dog.
IDs must comply with tight naming scheme. For example, "123" is not a valid value for an ID.

Instead, KEY and KEYREF should be used. And if you really need to insure uniqueness, use xs:unique\` to add a uniqueness constraint.

```xml Bad theme={null} ToDo ``` ```xml Fix theme={null} ToDo ```

\`DefaultMessageListenerContainer is implemented as a JMS poller. While the Spring container is shutting itself down, as each in-progress JMS Consumer.receive() call completes, any non-null return value will be a JMS message that the DMLC will discard due to the shutdown in progress. That will result in the received message never being processed.

To prevent message loss during restart operations, set acceptMessagesWhileStopping to true\` so that such messages will be processed before shut down.

```xml Bad theme={null} ``` ```xml Fix theme={null} ```

backup mechanism that can save and restore application data. When application backup is enabled, local data from your application can be exported to Google Cloud or to an external device via adb backup. Enabling Android backup exposes your application to disclosure of sensitive data. It can also lead to corruption of local data when restoration is performed from an untrusted source.

By default application backup is enabled and it includes:

Shared preferences files
Files saved in one of the paths returned by

```xml Bad theme={null} ``` ```xml Fix theme={null} ```

Namespace prefixes that are declared but not used simply clutter the document and confuse maintainers. Such prefixes should be removed.

```xml Bad theme={null} ... ``` ```xml Fix theme={null} ... ```

ve a large impact on user privacy, marked as dangerous or "not for use by third-party applications" by Android, should be requested only if they are really necessary to implement critical features of an application.

```xml Bad theme={null} ``` ```xml Fix theme={null} ```

The use of any value but "validate" for hibernate.hbm2ddl.auto may cause the database schema used by your application to be changed, dropped, or cleaned of all data. In short, the use of this property is risky, and should only be used in production with the "validate" option, if it is used at all.

```xml Bad theme={null} update ``` ```xml Fix theme={null} validate ```

system dependencies are sought at a specific, specified path. This drastically reduces portability because if you deploy your artifact in an environment that’s not configured just like yours is, your code won’t work.

```xml Bad theme={null} javax.sql jdbc-stdext 2.0 system /usr/bin/lib/rt.jar ``` ```xml Fix theme={null} ```

It can be tempting to set \`elementFormDefault to unqualified, because it allows XML document authors to remove a few prefixes in their files. However this is not a good practice for several reasons:

The unqualified form doesn’t convey any functionality.
Most XML schemas are qualified, so defining a few unqualified schemas requires the author of an XML document to fully master both cases with no added value.
The unqualified form implies that in the XML document, all global elements from the schema must be qualified, and all local elements must be unqualified. So the author must be very cautious regarding the local vs. global nature of each element.
The unqualified form implies that in an XML document, the default namespace cannot be used. This stems from the fact that a document’s default namespace qualifies all prefix-less elements, and an element cannot be both qualified and unqualified. For the XML document author, being prevented from using the default namespace is a real nuisance.
In some cases, the unqualified form degrades performance, by requiring the processing tool to look up the unqualified\` elements in the schema file.

```xml Bad theme={null} ... ``` ```xml Fix theme={null} ... ```

Deprecated features are those that have been retained temporarily for backward compatibility, but which will eventually be removed. In effect, deprecation announces a grace period to allow the smooth transition from the old features to the new ones. In that period, no use of the deprecated features should be added, and all existing uses should be gradually removed.

This rule raises an issue when \$\{pom.\*} properties are used in a pom.

```xml Bad theme={null} ${pom.artifactId}-${pom.version} ``` ```xml Fix theme={null} ${project.artifactId}-${project.version} ```

Whether they are disallowed locally for security, license, or dependability reasons, forbidden dependencies should not be used.

This rule raises an issue when the group or artifact id of a direct dependency matches the configured forbidden dependency pattern.

```xml Bad theme={null} log4j log4j 1.2.17 ``` ```xml Fix theme={null} ```

Exclusions for default interceptors can be declared either in xml or as class annotations. Since annotations are more visible to maintainers, they are preferred.

```xml Bad theme={null}

MyExcludedClass

true

doTheThing

``` ```xml Fix theme={null} @ExcludeDefaultInterceptors public class MyExcludedClass implements MessageListener { @ExcludeClassInterceptors @ExcludeDefaultInterceptors public void doTheThing() { // ... } ```

The \ group element isn’t supported universally among web service stacks. That means that if you use it, you may end up failing to transmit your data (in the resulting XML files) to systems that can’t process it. For that reason, \ should be used instead. The only constraint imposed by the use of an \ is the order it imposes, but that is usually a benefit for human readers.

```xml Bad theme={null} ``` ```xml Fix theme={null} ```

Use of a Spring \`SingleConnectionFactory without enabling the reconnectOnException setting will prevent automatic connection recovery when the connection goes bad.

That’s because the reconnectOnException property defaults to false. As a result, even if the code that uses this connection factory (Spring’s DefaultMessageListenerContainer or your own code) has reconnect logic, that code won’t work because the SingleConnectionFactory will act like a single-connection pool by preventing connection close calls from actually closing anything. As a result, subsequent factory create operations will just hand back the original broken Connection\`.

```xml Bad theme={null}

``` ```xml Fix theme={null}

```

It makes sense to handle all related actions in the same place. Thus, the same \`\ might logically handle all facets of CRUD on an entity, with no confusion in the naming about which \ handles which facet. But go very far beyond that, and it becomes difficult to maintain a transparent naming convention.

So to ease maintenance, this rule raises an issue when an \ has more than the allowed number of \\` tags.

```xml Bad theme={null} ``` ```xml Fix theme={null} ```

+is used to set a single permission for both reading and writing data from a content provider. In regard to the Principle of Least Privilege, client applications that consume the content provider should only have the necessary privileges to complete their tasks. As android:permission grants both read and write access, it prevents client applications from applying this principle. In practice, it means client applications that require read-only access will have to ask for more privileges than what they need: the content provider will always grant read and write together.

```xml Bad theme={null} android:exported="true"/> ``` ```xml Fix theme={null} android:writePermission="com.example.app.PERMISSION" android:exported="true"/> ```

Shared naming conventions allow teams to collaborate effectively. This rule raises an issue when a pom’s artifactId does not match the provided regular expression.

```xml Bad theme={null} My_Project ``` ```xml Fix theme={null} my-project ```

Schema versioning is a big topic, with best practices rather than hard-and-fast rules. One of these best practices is to include the version attribute in the xsd:schema and increment it to indicate minor changes. Nothing breaks if the value changes, but it does give the user a relatively prominent indication that something has changed.

```xml Bad theme={null} ... ``` ```xml Fix theme={null} ... ```

Omitting the data type of an attribute or element leaves it to default to xs:any for elements, and xs:anyType for attributes. However there is no reason for making such a significant design decision implicit..

```xml Bad theme={null} ``` ```xml Fix theme={null} ```

The prolog header is the following piece of code that some XML documents start with:

When the prolog exists in an XML document, it should be at the beginning of the file to enable programs to determine the encoding of non-UTF-8, non-UTF-16 files.

```xml Bad theme={null} content ``` ```xml Fix theme={null} content ```

Complex types can be restricted by means of an \`xs:restriction element. But restriction is anti-inheritance: the derived type has less information than the base type. Further, restriction causes the redefinition of the complex types elements and attributes, which leads to fragility in your XML schema; any change to a super type will require corresponding changes in all restricting subtypes, even those in other schemas. For example, if the base type defines a mandatory "color" element of type xs:int, the restricting type must also define a "color" element whose type cannot be, say, xs:string.

xs:extension\`, on the other hand, allows the extending element to inherit the base class' elements and add new ones.

```xml Bad theme={null} ``` ```xml Fix theme={null} ```

Shared naming conventions allow teams to collaborate efficiently. This rule checks that all element names match a provided regular expression.

```xml Bad theme={null} ... ``` ```xml Fix theme={null} ... ```

Sharing naming conventions allows teams to collaborate efficiently. This rule checks that type names match a provided regular expression.

```xml Bad theme={null} ... ``` ```xml Fix theme={null} ... ```

Shared naming conventions allow teams to collaborate effectively. This rule raises an issue when the a pom’s groupId does not match the provided regular expression.

```xml Bad theme={null} myCo ``` ```xml Fix theme={null} com.myco ```

Once an Android component has been exported, it can be used by attackers to launch malicious actions and might also give access to other components that are not exported. For this reason, the following components should be protected:

Providers
Activities
Activity-aliases
Services

```xml Bad theme={null} ``` ```xml Fix theme={null} ```

Having multiple prefixes for the same namespace is highly likely to confuse users and maintainers of the schema.

```xml Bad theme={null} ... ``` ```xml Fix theme={null} ... ```

Namespaces act as a container for grouping together permissions with a common theme or purpose. They also prevent conflicts when multiple apps want to use the same permission name.

The \`android.permission namespace holds all of the permissions defined by the Android operating system. It is not intended to be a general use container for all permissions.

Defining permissions in the android.permission\` namespace increases the risk of a permission name collision. The collision could be due to a new Android system permission, or it could be due to another app using the same permission name.

```xml Bad theme={null} ``` ```xml Fix theme={null} ```

Having a permissive Cross-Origin Resource Sharing policy is security-sensitive. It has led in the past to the following vulnerabilities:

Same origin policy in browsers prevents, by default and for security-reasons, a javascript frontend to perform a cross-origin HTTP request to a resource that has a different origin (domain, protocol, or port) from its own. The requested target can append additional HTTP headers in response, called CORS, that act like directives for the browser and change the access control policy / relax the same origin policy.

```xml Bad theme={null}

CorsFilter

org.apache.catalina.filters.CorsFilter

cors.allowed.origins

https://trusted1.org,https://trusted2.org

``` ```xml Fix theme={null} ```

Clear-text protocols such as \`ftp, telnet, or http lack encryption of transported data, as well as the capability to build an authenticated connection. It means that an attacker able to sniff traffic from the network can read, modify, or corrupt the transported content. These protocols are not secure as they expose applications to an extensive range of risks:

sensitive data exposure
traffic redirected to a malicious endpoint
malware-infected software update or installer
execution of client-side code
corruption of critical information

Even in the context of isolated networks like offline environments or segmented cloud environments, the insider threat exists. Thus, attacks involving communications being sniffed or tampered with can still happen.

For example, attackers could successfully compromise prior security layers by:

bypassing isolation mechanisms
compromising a component of the network
getting the credentials of an internal IAM account (either from a service account or an actual person)

In such cases, encrypting communications would decrease the chances of attackers to successfully leak data or steal credentials from other network components. By layering various security practices (segmentation and encryption, for example), the application will follow the defense-in-depth principle.

Note that using the http\` protocol is being deprecated by major web browsers.

In the past, it has led to the following vulnerabilities:

```xml Bad theme={null} ``` ```xml Fix theme={null} ```

When a cookie is configured with the HttpOnly attribute set to true, the browser guaranties that no client-side script will be able to read it. In most cases, when a cookie is created, the default value of HttpOnly is false and it’s up to the developer to decide whether or not the content of the cookie can be read by the client-side script. As a majority of Cross-Site Scripting (XSS) attacks target the theft of session-cookies, the HttpOnly attribute can help to reduce their impact as it won’t be possible to exploit the XSS vulnerability to steal session-cookies.

```xml Bad theme={null}

true

``` ```xml Fix theme={null} ```

To reduce the risk of cross-site scripting attacks, templating systems, such as \`Twig, Django, Smarty, Groovy's template engine, allow configuration of automatic variable escaping before rendering templates. When escape occurs, characters that make sense to the browser (eg: \) will be transformed/replaced with escaped/sanitized values (eg: & lt;a& gt; ).

Auto-escaping is not a magic feature to annihilate all cross-site scripting attacks, it depends on the strategy applied and the context, for example a "html auto-escaping" strategy (which only transforms html characters into html entities) will not be relevant when variables are used in a html attribute because ':’ character is not escaped and thus an attack as below is possible:

\link\ // myLink = javascript:alert(document.cookie)
        \link\ // JS injection (XSS attack)

```xml Bad theme={null}

defaultHtmlEscape

true

``` ```xml Fix theme={null} ```

Android applications can receive broadcasts from the system or other applications. Receiving intents is security-sensitive. For example, it has led in the past to the following vulnerabilities:

Receivers can be declared in the manifest or in the code to make them context-specific. If the receiver is declared in the manifest Android will start the application if it is not already running once a matching broadcast is received. The receiver is an entry point into the application.

Other applications can send potentially malicious broadcasts, so it is important to consider broadcasts as untrusted and to limit the applications that can send broadcasts to the receiver.

Permissions can be specified to restrict broadcasts to authorized applications. Restrictions can be enforced by both the sender and receiver of a broadcast. If permissions are specified when registering a broadcast receiver, then only broadcasters who were granted this permission can send a message to the receiver.

This rule raises an issue when a receiver is registered without specifying any broadcast permission.

```xml Bad theme={null}

``` ```xml Fix theme={null}

```

Developers often use TODO tags to mark areas in the code where additional work or improvements are needed but are not implemented immediately. However, these TODO tags sometimes get overlooked or forgotten, leading to incomplete or unfinished code. This rule aims to identify and address unattended TODO tags to ensure a clean and maintainable codebase. This description explores why this is a problem and how it can be fixed to improve the overall code quality.

```xml Bad theme={null} org.apache.commons commons-lang3 3.8.1 ``` ```xml Fix theme={null} ```

Because it is easy to extract strings from an application source code or binary, credentials should not be hard-coded. This is particularly true for applications that are distributed or that are open-source.

In the past, it has led to the following vulnerabilities:

Credentials should be stored outside of the code in a configuration file, a database, or a management service for secrets.

This rule flags instances of hard-coded credentials used in database and LDAP connections. It looks for hard-coded credentials in connection strings, and for variable names that match any of the patterns from the provided list.

It’s recommended to customize the configuration of this rule with additional credential words such as "oauthToken", "secret", …

```xml Bad theme={null} @Configuration public class SocialConfig implements SocialConfigurer { @Override public void addConnectionFactories(ConnectionFactoryConfigurer cfConfig, Environment env) { cfConfig.addConnectionFactory(new TwitterConnectionFactory( env.getProperty("twitter.consumerKey"), env.getProperty("twitter.consumerSecret"))); } } ``` ```xml Fix theme={null} ```

Consistent indentation is a simple and effective way to improve the code’s readability. It reduces the differences that are committed to source control systems, making code reviews easier.

This rule raises an issue when the indentation does not match the configured value. Only the first line of a badly indented section is reported.

```xml Bad theme={null} Gambardella, Matthew XML Developer's Guide Computer 44.95 2000-10-01 An in-depth look at creating applications with XML. Ralls, Kim Midnight Rain Fantasy 5.95 2000-12-16 A former architect battles corporate zombies, an evil sorceress, and her own childhood to become queen of the world. ``` ```xml Fix theme={null} Gambardella, Matthew XML Developer's Guide Computer 44.95 2000-10-01 An in-depth look at creating applications with XML. Ralls, Kim Midnight Rain Fantasy 5.95 2000-12-16 A former architect battles corporate zombies, an evil sorceress, and her own childhood to become queen of the world. ```