Broken Access Control

In application security, authentication and authorization are fundamentally intertwined. Authentication establishes identity by answering, "Who are you?", while authorization determines access rights with the question, "What are you allowed to do?". When either of these processes fails or, worse, both are compromised, it leads to what is broadly termed "Broken Auth or Broken Authentication." This term encompasses a diverse array of vulnerabilities that enable attackers to impersonate users, escalate their privileges, or circumvent essential security measures. "Broken Auth" is widely recognized within secure coding guidelines and threat modeling discussions as a shorthand for critical access control weaknesses that jeopardize application security.

Contexts of Authentication

Broken authentication vulnerabilities can manifest in various contexts within an application ecosystem. It's important to consider these different scenarios:

User Interface (UI) Logins: This is the most common context, where users log into a web application (e.g., Guidewire PolicyCenter, ClaimCenter, or BillingCenter) via a login page. Here, Vulnerabilities include weak password policies, susceptibility to brute-force attacks, or improper session management.
API Authentication: Applications increasingly rely on APIs for data exchange and functionality. Securing these APIs is critical. Broken authentication in APIs can involve missing or weak API key/token validation, allowing unauthorized systems or users to access or manipulate data. This is especially crucial for Guidewire implementations that connect to other systems.
Service-to-Service Authentication: In microservices architectures or distributed systems, services often need to authenticate. Flaws here could allow a compromised service to impersonate another, leading to broader system compromise.
Single Sign-On (SSO) Integrations: While SSO solutions like Okta (as mentioned for Guidewire Cloud Platform ) centralize authentication, misconfigurations in the SSO integration or the Identity Provider (IdP) itself can lead to vulnerabilities. It's noted that MFA enforcement is the customer's responsibility through their IdP.

What is Authentication?

Authentication is the process of verifying the identity of a user or system. Broken Authentication encompasses flaws that permit unauthorized access, such as:

Weak password policies
Session management vulnerabilities
Improper implementation of authentication protocols

In Guidewire applications, authentication is crucial for safeguarding policyholder information and ensuring only authorized personnel can access specific functionalities.

What Can Go Wrong with Authentication?

Exploits	Discription	Example
Credential Stuffing	Attackers use lists of compromised usernames and passwords from other breaches to gain unauthorized access.	An attacker uses lists of usernames and passwords from other breaches to gain unauthorized access to Guidewire ClaimCenter, potentially viewing or modifying sensitive claimant data.
Session Hijacking	Exploiting vulnerabilities to steal or manipulate active user sessions.	An attacker captures an active session ID of an adjuster logged into Guidewire PolicyCenter (e.g., through an XSS attack if session cookies aren't properly secured with HttpOnly), allowing them to impersonate the adjuster and access or alter policy information.
Brute Force Attacks	Systematically attempting all possible password combinations to gain access.	An attacker uses automated tools to systematically try common password combinations against the Guidewire BillingCenter login page. If account lockout policies are not enforced by the underlying Identity Provider (IdP), this could lead to unauthorized access.
Insufficient Authentication	Lack of multi-factor authentication (MFA) increases risk.	Users, such as underwriters or claims adjusters, access sensitive policyholder data within Guidewire applications using only single-factor (password-only) authentication. This makes their accounts more susceptible to compromise if those passwords are weak, reused, or compromised through phishing, especially since MFA enforcement is a customer responsibility via their Identity Provider (IdP). An external service integrated with a Guidewire Suite API (e.g., for address lookup) uses a weak, non-expiring API key for authentication. If this key is compromised, an attacker could gain unauthorized access to API functionalities and data.
Unvalidated Redirects	Improper handling of URLs can lead users to malicious sites.	An attacker crafts a URL with a malicious redirect parameter targeting a legitimate Guidewire application. If the application doesn't validate the redirect URL, a user clicking this link might be unknowingly sent to a phishing site designed to look like the Guidewire login page to steal their credentials.

Broken authentication occurs when an application's verification process is flawed. These flaws can allow attackers to pretend to be other users, putting sensitive information and the system at risk. In Guidewire implementations, especially those that connect to other systems, strong authentication methods are crucial to keeping everything secure and trustworthy.

Authentication Defense Strategies

Broken authentication vulnerabilities can be mitigated by implementing layered, proactive defense strategies.

The following best practices help ensure that only authorized users and services can access sensitive systems and data within Guidewire environments.

Multi-Factor Authentication (MFA)

Multi-factor authentication (MFA) requires users to present two or more independent verification factors to gain access—typically something they know (like a password), something they have (like a phone or hardware token), or something they are (like a fingerprint). This layered defense significantly reduces the likelihood of unauthorized access, even if user credentials are compromised.

Guidewire Cloud Platform supports Single Sign-On (SSO) through Okta, but MFA is not enabled out-of-the-box in Guidewire products. Instead, MFA enforcement is the customer's responsibility through their Identity Provider (IdP).

Guidewire Cloud Platform supports SSO via Okta; MFA must be configured in your IdP.

Best practice: MFA

For example, when a claims manager attempts to log into Guidewire ClaimCenter and enters their password, their IdP (such as Okta, which Guidewire Cloud Platform supports for SSO) prompts them for a one-time code from their authenticator app. This prevents access even if their password was compromised.

Strong Password Policies

Passwords remain a primary authentication factor for many systems. Weak or reused passwords are highly susceptible to brute-force attacks, credential stuffing, and phishing.

While Guidewire products support integration with SSO providers, the enforcement of strong password policies should be configured and maintained by the customer within their chosen identity platform.

Best practice: Passwords

Users should avoid using short, simple passwords, as these are easily guessed or cracked. Longer, more complex passwords or passphrases provide significantly better security. When a user sets up their account or changes their password for accessing any Guidewire application via the customer's Identity Provider (IdP), the IdP should enforce strong password creation. This includes preventing the use of easily guessable passwords (e.g., 'Password123,' 'admin'), dictionary words, and, critically, passwords known to have been compromised in previous data breaches. This enforcement is managed within the customer's chosen identity platform. For comprehensive guidance on password policies, refer to standards from credible organizations like the National Institute of Standards and Technology (NIST), such as NIST SP 800-63B.

Secure Session Management

Sessions represent authenticated user interactions. If not properly managed, attackers can hijack sessions or maintain access after logout.

Best practice: Sessions

Effective session management within the Guidewire ecosystem involves several key security measures, often coordinated between the Guidewire platform, the customer's Identity Provider (IdP), and any custom code developed:

Configuring Secure Cookie Attributes for Guidewire Sessions: Session cookies used by Guidewire applications, whether set by the platform, an integrated IdP, or custom Guidewire extensions, must be properly secured. This means:
- Setting the HttpOnly flag to prevent client-side scripts (e.g., JavaScript in PCF files or custom web components) from accessing the session cookie. This is crucial for protecting Guidewire user sessions from XSS-based session theft.
- Setting the Secure flag to ensure that session cookies for Guidewire applications are only transmitted over encrypted HTTPS connections.
- Using the SameSite attribute (e.g., Strict or Lax) on cookies to protect Guidewire applications against cross-site request forgery (CSRF) attacks, complementing platform-specific defenses like Guidewire's use of CSRF tokens for session-based authentication.
Relying on Strong Platform-Generated Session Identifiers: The generation of session IDs for Guidewire applications is typically handled by the underlying platform (e.g., the application server running Guidewire) or the integrated IdP during SSO. Secure coding practice for Guidewire developers involves relying on these robust, platform-generated identifiers rather than attempting to create custom session management logic.
Ensuring Session ID Regeneration upon Guidewire Authentication: To prevent session fixation attacks, session IDs must be regenerated after a user successfully authenticates into a Guidewire application. The IdP usually manages this critical security step during the SSO handshake or by the Guidewire platform itself. Any custom code involved in or interacting with authentication flows must not interfere with this process.
Implementing Robust Session Lifecycle Controls for Guidewire Users: This involves diligently managing when and how Guidewire user sessions begin and end.
- For example, if an underwriter is logged into Guidewire PolicyCenter and leaves their workstation unattended, their session should automatically time out after a pre-defined period (e.g., 15 minutes) of inactivity. This timeout is often configured at the IdP level or via application server settings for the Guidewire deployment.
- Furthermore, when a user explicitly logs out from any Guidewire application, such as ClaimCenter or BillingCenter, the session must be properly and immediately invalidated on the server-side. Any custom logout buttons or mechanisms added to Guidewire UIs must ensure they trigger this complete server-side invalidation process, not just a client-side cleanup.

Unlimited login attempts make systems vulnerable to brute-force attacks, where automated tools try many password combinations.

Rate-limiting and account lockout mechanisms are not enforced directly by Guidewire products but can be implemented through customer-managed identity providers.

If an attacker attempts to brute-force a user's password at the login page for a Guidewire application, the customer-managed Identity Provider (IdP) should lock the account (e.g., for 30 minutes after five failed attempts) or trigger a CAPTCHA. This is crucial as these mechanisms are not directly enforced by Guidewire products themselves.

Use Secure Authentication Protocols

Modern authentication protocols offer protection against common attacks, such as replay attacks, token misuse, and insecure credential transmission.

Guidewire supports industry-standard protocols such as SAML and OAuth2 through SSO integrations. Basic Authentication should not be used.

Best practice

For user authentication into Guidewire Suite, SAML should be used with the customer's IdP. When building custom integrations that interact with Guidewire APIs, OAuth2 should be the preferred method for service-to-service authentication, rather than relying on insecure methods like Basic Authentication (which should be disabled).

What is Authorization?

Authorization determines what an authenticated user is allowed to do. Vulnerabilities occur when applications fail to enforce access controls, allowing users to perform actions or access data beyond their intended privileges.

Common Exploits include:

Insecure Direct Object Reference (IDOR)
Directory Traversal
Privilege Escalation
Missing or improper role validation

What Can Go Wrong with Authorization?

Exploits	Discription	Example
IDOR	Users access data by changing identifiers.	A policyholder views another’s claim by modifying a URL parameter.
Directory Traversal	Accessing files outside the intended directory.	App allows reading `/etc/passwd` via crafted input.
Privilege Escalation	Users gain unauthorized permissions.	A regular user changes their role to `admin` using a proxy tool.
Role Bypass	App doesn’t enforce role restrictions server-side.	A non-admin user accesses an admin endpoint via direct API call.

Authorization Defense Strategies

Authorization vulnerabilities can be mitigated by implementing structured, server-side access controls and enforcing least privilege throughout your application. The following best practices help ensure that only users with the appropriate permissions can access specific resources and perform sensitive actions in Guidewire environments.

Role-Based Access Control (RBAC)

RBAC ensures users only access what they’re permitted to by assigning roles with clearly defined privileges. Roles should be scoped appropriately (e.g., user, adjuster, administrator), and access should be validated on every request.

Guidewire provides support for implementing role-based access within its configuration layers, including permissions tied to PCF screens, Gosu business logic, and REST API access.

Best practice: RBAC

Use Guidewire role configuration to enforce role-based restrictions consistently across PCF screens, API endpoints, workflows, and custom extensions.

Authorization Matrix

An authorization matrix is a documented mapping of what each role is allowed to do within the system. This helps validate that the implementation matches the intended access model.

Best practice: Authorization Matrix

Create and maintain an up-to-date matrix of roles, resources, and permitted actions. Review it during design, development, and security testing phases.

Avoid Client-Side Enforcement

Client-side role checks (e.g., hiding UI elements) do not provide true protection—attackers can manipulate requests or use proxies to access hidden functionality.

Best practice: Server-Side Enforcement

Ensure all critical authorization logic is implemented and enforced on the server. Use backend services to check user roles and permissions before granting access to protected data or actions.

Recheck on Role Changes

User permissions may change during a session (e.g., role downgrade or removal). Applications should account for this by re-evaluating authorization during each sensitive operation.

Best practice: Dynamic Authorization Checks

Use short-lived access tokens or session validation strategies that tie privileges to the current user state.

Testing & Tooling

Security tools and manual tests can help identify authorization weaknesses like privilege escalation or IDOR (Insecure Direct Object Reference).

Best practice: Authorization Testing

Use tools like Burp Suite, OWASP ZAP, or Postman to intercept and modify requests. Simulate lower-privileged users attempting to perform higher-privilege operations or access unauthorized resources. Validate that unauthorized attempts are correctly denied.

Shared Responsibility

While Guidewire provides built-in authentication mechanisms, customers are responsible for:

Ensuring that custom integrations enforce authentication securely
Managing user roles and access control in their implementation
Monitoring audit logs and taking action on anomalies
Keeping credentials, secrets, and tokens secure

Additional Resources

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

Guidewire:

OWASP:

NIST:

NIST SP 800-63B.

Was this page helpful?

Contexts of Authentication​

What is Authentication?​

What Can Go Wrong with Authentication?​

Authentication Defense Strategies​

Multi-Factor Authentication (MFA)​

Best practice: MFA​

Strong Password Policies​

Best practice: Passwords​

Secure Session Management​

Best practice: Sessions​

Limit Login Attempts​

Best practice: Limit Login Attempts​

Use Secure Authentication Protocols​

Best practice​

What is Authorization?​

What Can Go Wrong with Authorization?​

Authorization Defense Strategies​

Role-Based Access Control (RBAC)​

Best practice: RBAC​

Authorization Matrix​

Best practice: Authorization Matrix​

Avoid Client-Side Enforcement​

Best practice: Server-Side Enforcement​

Recheck on Role Changes​

Best practice: Dynamic Authorization Checks​

Testing & Tooling​

Best practice: Authorization Testing​

Shared Responsibility​

Additional Resources​