Xml

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

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 <xs:schema> tag, nor <xsd:annotation><xsd:documentation>…</xsd:documentation></xsd:annotation> just inside the <xs:schema> element.

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

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:

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.

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.

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:

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.

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.

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.

`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.

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”. If you subvert that expected correspondence, you run the risk of severely confusing the users of your XSD.

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.

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

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

`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.

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:

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

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.

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.

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.

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:

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.

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.

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

The <xs:all> 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, <xs:sequence> should be used instead. The only constraint imposed by the use of an <xs:sequence> is the order it imposes, but that is usually a benefit for human readers.

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`.

It makes sense to handle all related actions in the same place. Thus, the same `<action> might logically handle all facets of CRUD on an entity, with no confusion in the naming about which <forward/> 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 <action> has more than the allowed number of <forward/>` tags.

+ 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.

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.

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.

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..

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.

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.

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

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

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.

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:

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

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.

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.

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:

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:

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:

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.

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: <a>) 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:

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.

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.

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”, …​

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.