Apply more code review suggestions

Author: jvz

src/site/asciidoc/security.adoc

@@ -59,13 +59,15 @@ Specific security considerations involved in our threat model are detailed below
 When using a log message containing template parameters like `{}`, only the format string is evaluated for parameters to be substituted.
 The message parameters themselves are not evaluated for parameters; they are only included in the format string corresponding to their template position.
 The conversion of message parameters into a string is done on-demand depending on the layout being used.
-When structure-preserving transformations of log message data are required, the `Message` API should be used for logging structured data.
+When structure-preserving transformations of log message data are required, the `Message` API should be used for logging structured data combined with a structured layout (e.g., `JsonTemplateLayout`).
+Format strings should be compile-time constants, and under no circumstances should format strings be built using user-controlled input data.
 
 === Unstructured Logging
 
 When using an unstructured layout such as `PatternLayout`, no guarantees can be made about the output format.
 This layout is mainly useful for development purposes and should not be relied on in production applications.
 For example, if a log message contains new lines, these are not escaped or encoded specially unless the configured pattern uses the `%encode{pattern}{CRLF}` wrapper pattern converter (which will encode a carriage return as the string `\r` and a line feed as the string `\n`) or some other `%encode` option.
+Note that `%xEx` is appended to the pattern unless already present.
 Similarly, other encoding options are available for other formats, but pattern layouts cannot make assumptions about the entire output.
 As such, when using unstructured layouts, no user-controlled input should be included in logs.
 It is strongly recommended that a structured layout (e.g., `JsonTemplateLayout`) is used instead for these situations.
@@ -115,14 +117,6 @@ When configurations are modified through JMX, the JMX server should be safely co
 When configurations are provided through JNDI, these should only use the `java` scheme for sharing configurations in a JavaEE or JakartaEE application service.
 JNDI-sourced configurations should not use other JNDI providers such as LDAP, DNS, or RMI, as all these providers are difficult to properly secure.
 
-=== Cryptographic Logs
-
-When using custom plugins to calculate message authentication codes, signatures, or encrypted logs, proper key management must be considered.
-Cryptography is a tricky subject, and key management lies at the heart of most design problems to solve when using it.
-If a custom plugin relies on a pre-shared key or password of some sort, it is likely broken beyond repair if being used for cryptographic purposes.
-Proper key management typically uses public key infrastructure (PKI) such as X.509 certificates, though this is not the only option.
-It is beyond the scope of Log4j to implement key management as this would depend on other infrastructure in use for validating or decrypting logs combined with the deployment and runtime environment of the logging application.
-
 === Compressing Logs
 
 If log compression is used along with custom encryption where logs contain user-controlled input, then this can lead to a https://en.wikipedia.org/wiki/CRIME[CRIME attack] style vulnerability where a chosen-plaintext attack is combined with information leakage caused by how the compression algorithm handles different inputs.