An unsigned timestamp can leave a SOAP message open to tampering and replay attacks.
A Security timestamp indicates a message's freshness. If an attacker intercepts a message retransmits it at a later time, the receiver can reject the replay attack because the timestamp will indicate that the message is stale. Optionally, timestamps can include an expiration attribute which places a hard limit on how long security semantics are valid.
To prevent attackers from tampering with timestamps, timestamps should be signed. Without a signed timestamp, an attacker can intercept a SOAP message, modify the timestamp, and send the message on without the receiver's knowledge. Under these circumstances, an attacker can potentially trick a recipient into accepting a malicious message.
The following snippet from a WSE policy file is an example where timestamps are not include in SOAP message requests:
<policies xmlns="http://schemas.microsoft.com/wse/2005/06/policy">
...
<protection>
<request signatureOptions="IncludeAddressing, IncludeSoapBody" encryptBody="true" />
[1]
[2] Standards Mapping - OWASP Top 10 2004 - (OWASP 2004) A10 Insecure Configuration Management
[3] Standards Mapping - OWASP Top 10 2010 - (OWASP 2010) A6 Security Misconfiguration
[4] Standards Mapping - FIPS200 - (FISMA) CM
[5] Standards Mapping - Common Weakness Enumeration - (CWE) CWE ID 345
[6] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 - (PCI 1.1) Requirement 6.5.10