Logging Sensitive Information - Credentials

---

What is is?

Credentials are the login details or access keys, like usernames, passwords, or tokens, that verify your identity and grant access to applications. Credentials serve as the keys to systems, services, and data. Logging these unintentionally can lead to unauthorized access, data loss, and regulatory violations. Examples of sensitive credentials include:

• Passwords – User passwords for authentication.
• API Keys – Keys that grant access to APIs.
• Access Tokens – Temporary tokens used in OAuth-based authentication.
• Session IDs – Identifiers tied to user sessions, often used for state management.
• Private Keys – Keys used for encryption and digital signatures.
• Certificate Secrets – Credentials embedded in certificates

Logging such information in plaintext increases the risk of exposure, especially in shared or centralized logging systems. Even brief exposure of credentials can have severe consequences, as attackers or unauthorized users may exploit these secrets immediately.

What Can Go Wrong?

When credentials are logged, they expose critical secrets that attackers can exploit to gain unauthorized access. This exposure can lead to significant security incidents and undermine trust in your organization.

Some of the most common issues that can arise from logging sensitive data include:

Name	Discription	Example
Unauthorized Access	Logs containing plaintext credentials can be accessed by unauthorized users, leading to system compromises.	A server log captures and stores a user’s login password in plaintext, accessible to support staff.
Token Hijacking	Exposed access tokens in logs can allow attackers to impersonate users or services.	An OAuth access token is logged during an API call and intercepted by an attacker monitoring logs.
Regulatory Violations	Logging credentials without protection may breach compliance standards like PCI-DSS or ISO 27001.	Passwords in logs violate PCI-DSS Requirement 3, which mandates secure storage of cardholder data.
Persistent Exposure	Credentials in archived logs remain at risk long after they are no longer relevant.	An old log archive contains unredacted session IDs from an application no longer in use.
Credential Reuse	Attackers in credential stuffing or brute-force attacks may reuse credentials captured in logs.	Logged API keys are harvested and reused by attackers to gain unauthorized access to cloud services.

What Are The Impacts?

Logging sensitive credential information can lead to the following critical consequences:

1. Unauthorized Access – Exposed credentials allow attackers to gain direct access to systems, bypassing traditional security controls.
2. Credential Compromise – Once logged credentials are accessed by attackers, they can be used to escalate privileges or impersonate legitimate users.
3. Regulatory Non-Compliance – Exposing credentials in logs may violate industry regulations, such as:
   • PCI-DSS – For payment card handling.
   • SOC 2 – For safeguarding sensitive data during audits.
4. Operational Downtime – Compromised credentials may lead to service interruptions as teams scramble to rotate secrets and investigate incidents.
5. Reputation Damage – Incidents caused by leaked credentials can erode customer trust and harm brand reputation.

What Are The Defense Strategies?

Don't Log Credentials

Avoiding the logging of credentials is a foundational defence strategy in safeguarding sensitive information. Organizations should adopt a structured approach to their logging practices to achieve this. First, developers must carefully review and sanitize any data written to logs. This involves ensuring that any information being logged has been inspected for sensitive content, particularly fields where credentials are commonly stored, such as passwords, API keys, session tokens, and private cryptographic keys.

While the principle of "don't log credentials" seems straightforward, its implementation can be deceptively complex due to the wide variety of data that qualify as credentials. Credentials extend beyond obvious fields like password or secret_key and include anything that grants access or authentication. This diversity introduces the risk of accidentally logging credentials that don't conform to standard naming or structure.

A technique to help accomplish this is to adopt a whitelist approach, explicitly specifying which data fields can be logged while assuming all others are sensitive by default. Maintaining and reviewing this list provides an invaluable resource for development teams. The following is a non-exhaustive list of Credentials to get you started.

Type of Credential	Discription	Example
Password	A user-defined string used for authentication.	MyP@ssw0rd123
API Key	A token used to authenticate API requests.	abcd1234efgh5678
Session Token	A temporary key issued after login for session tracking.	eyJhbGciOiJIUzI1NiIsInR5c...
Private Key	A cryptographic key for secure communications.	-----BEGIN PRIVATE KEY-----
OAuth Access Token	A token granting access to OAuth-protected resources.	ya29.a0AfH6SM...
Password Reset Token	A token sent to users to reset their password.	reset123456789
JSON Web Token (JWT)	A compact, self-contained token for securely transmitting claims.	eyJhbGciOiJIUzI1NiIsInR5c...
AWS Access Keys	A key used to authenticate AWS requests.	AKIAIOSFODNN7EXAMPLE

// Bad Practice: Logging AWS access keys 
logger.info("AWS Access Key: " + awsAccessKey + " AWS Secret Key: " + awsSecretKey) 

// Good Practice: Avoid logging AWS access keys 
logger.info("AWS credentials used for operation.")

To help you construct your allowlist for logging, refer to Guidewire Cloud Standard IS-SEC-1008: Personally Identifiable Information. For guidance on what log levels to use for various data types, refer to Guidewire Cloud Standard IS-IMP-1017: Logging.

Don’t Log Header Information

Headers often contain sensitive data that is crucial for securing applications and services, such as authentication tokens, API keys, and session identifiers. Logging these headers without careful filtering can inadvertently expose this information, increasing the risk of unauthorized access if the logs are compromised. Organizations should implement a strict policy to avoid logging unfiltered header information in order to mitigate this risk.

One effective method is to use a denylist for headers known to carry sensitive data while also employing a whitelist approach to log only those headers that are explicitly considered safe. It is important to avoid blanket logging of all incoming and outgoing request headers. Instead, organizations should capture only the information necessary for debugging and operational monitoring, ensuring that no sensitive content is included.

Regular reviews of logging practices and header policies can help maintain compliance with privacy and security standards. Headers are often overlooked as a source of sensitive information, yet they can carry critical data such as JWT tokens, session cookies, and even personal details. Misconfigurations or a lack of awareness could result in accidental exposure. Below is a non-exhaustive list of headers that require careful handling:

Header Name	Discription	Example
Authorization	Used for authentication credentials.	Bearer eyJhbGciOiJIUzI1NiIs...
Cookie	May contain session IDs or tracking information.	SESSIONID=abc123xyz;
X-Api-Key	Custom header for API access keys.	X-Api-Key: abcd1234
X-Csrf-Token	CSRF protection token used in web forms.	X-Csrf-Token: xyz789
Set-Cookie	Response header for setting cookies (often contains sensitive session data).	Set-Cookie: SESSIONID=abc123; HttpOnly

// Bad Practice: Logging all headers including sensitive information
logger.info("Request headers: " + request.getHeaders())

// Good Practice: Logging only non-sensitive headers
logger.info("Request received with headers: " + request.getHeader("User-Agent"))

Implement Token and Key Rotation

Token and key rotation is a proactive strategy that minimizes the risk of sensitive credentials being misused if they are accidentally logged or exposed. By periodically replacing tokens, keys, and other credentials with new values, the window of opportunity for malicious actors to exploit leaked information is significantly reduced. This approach is particularly important for long-lived credentials such as API keys, JWTs, and encryption keys.

Automating token and key rotation is a best practice, as manual rotation can be error-prone and time-consuming. Many cloud platforms and identity providers offer built-in support for rotating credentials at regular intervals. Applications should be designed to handle rotated tokens and keys gracefully, ensuring minimal downtime or disruption during the process. For example, systems can implement overlapping validity periods where both the old and new credentials are accepted temporarily.

Additional Resources

To further strengthen your understanding and implementation, these resources provide additional guidance on secure coding practices.

• 8 Best Logging Practices to Keep Sensitive Data Out

• OWASP Cheat Sheet Series:

  • Logging Cheat Sheet
  • Error Handling

• Guidewire Cloud Standards

  • IS-IMP-1017: Logging
  • IS-INT-1091: Credentials Management
  • IS-INT-1317: Hard-Coded mTLS Keystores
  • IS-SEC-1007: Payment Card Handling
  • IS-SEC-1008: Personally Identifiable Information
  • IS-SEC-1332: Hard-Coding of Security Credentials

• Guidewire Documentation

  • Credentials plugin
  • SEC00-G: Do Not Hardcode Secrets
  • Secrets | Helios
  • Using API security

These resources provide detailed guidance on secure coding practices specific to Guidewire environments.

---

By incorporating these tailored strategies and examples, you'll enhance the security of logging within Guidewire applications.