wrapper.check_integrity.mode
Compatibility :3.7.0
Editions :Professional EditionStandard EditionCommunity Edition (Not Supported)
Platforms :WindowsMac OSXLinuxAlpine LinuxIBM AIXFreeBSDSolarisIBM z/Linux

At startup, the Wrapper computes and validates the hash of wrapper.jar and its associated native library to ensure they have not been modified, corrupted, or incorrectly upgraded.

The wrapper.check_integrity.mode property controls how the Wrapper verifies the integrity of these libraries.

Two modes are possible:

  • DEFAULT:

    In this mode, the Wrapper allows the libraries to be loaded during the bootstrap phase so it can collect metadata such as version and edition information. Their integrity is verified before the Java application is launched, and if a mismatch is detected, startup is aborted and an error is logged.

    This mode provides strong integrity protection for the Java application while preserving useful diagnostic information. In practice, most integrity check failures are caused by incomplete or incorrect library upgrades rather than malicious modification, and the metadata collected in this mode helps identify such issues quickly.

  • STRICT:

    In this mode, integrity verification is performed before the libraries are loaded. If verification fails, the libraries are not loaded at all and the Wrapper stops immediately.

    This mode provides a higher level of protection by ensuring that no unverified library is ever loaded into the process. However, it does not distinguish between the possible causes of a verification failure, such as a version or edition mismatch, file modification, or other inconsistencies.

    In environments where appropriate file system permissions prevent unauthorized modification of the libraries and their directories, strict mode is typically not necessary from a security perspective.

The default value is "DEFAULT".

Example: 
wrapper.check_integrity.mode=STRICT

NOTE

These integrity checks provide an additional layer of defense against tampering and deployment errors. However, they do not replace proper operating system-level file permissions. The wrapper.jar file, the native library, and any JARs used by the Java application should be placed in a secure location and protected with appropriate access controls to prevent unauthorized modification.