Skip to content

Fix DB Query Leak when passing too long Values to Users Endpoint - #4077

Draft
adrianhoelzl-sap wants to merge 6 commits into
developfrom
fix-db-internals-leak-when-passing-too-long-values-to-users-endpoint
Draft

adrianhoelzl-sap wants to merge 6 commits into
developfrom
fix-db-internals-leak-when-passing-too-long-values-to-users-endpoint

Conversation

@adrianhoelzl-sap

Copy link
Copy Markdown
Contributor

No description provided.

@github-project-automation github-project-automation Bot moved this from Inbox to Pending Merge | Prioritized in Foundational Infrastructure Working Group Sep 18, 2026
@strehle
strehle requested review from duanemay and gdgenchev and a lite review from Copilot September 19, 2026 14:08

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot review overview

🟡 Changes recommended

Database-error sanitization gaps and incomplete validation of persisted fields remain.

Get a fresh assessment by requesting another Copilot review.

Review effort: Lite
Findings: 2 High severity · 1 Medium severity

Open (3)
What changed in this PR

Adds SCIM field-length validation and database-error sanitization to prevent oversized user data from reaching database columns.

Changes:

  • Validates username, given name, and family name lengths.
  • Adds endpoint and unit tests for oversized values.
  • Adds database-error handling.
File Summary
uaa/​src/​test/​java/​org/​cloudfoundry/​identity/​uaa/​scim/​endpoints/​ScimUserEndpointsMockMvcTests.java Adds endpoint regression tests.
server/​src/​test/​java/​org/​cloudfoundry/​identity/​uaa/​scim/​util/​ScimUtilsTest.java Tests field-length validation boundaries.
server/​src/​main/​java/​org/​cloudfoundry/​identity/​uaa/​scim/​util/​ScimUtils.java Implements field-length validation.
server/​src/​main/​java/​org/​cloudfoundry/​identity/​uaa/​scim/​endpoints/​ScimUserEndpoints.java Applies validation and sanitizes database errors.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

// Never leak DB internals (SQL statements, column names, driver messages) to the caller
// for any DataAccessException not explicitly mapped to a status above.
if (e.getStatus() == HttpStatus.INTERNAL_SERVER_ERROR && t instanceof DataAccessException) {
e = new ScimException("A database error occurred.", t, HttpStatus.INTERNAL_SERVER_ERROR);
Comment on lines +654 to 660
// Never leak DB internals (SQL statements, column names, driver messages) to the caller
// for any DataAccessException not explicitly mapped to a status above.
if (e.getStatus() == HttpStatus.INTERNAL_SERVER_ERROR && t instanceof DataAccessException) {
e = new ScimException("A database error occurred.", t, HttpStatus.INTERNAL_SERVER_ERROR);
}
}
}
Comment on lines +118 to +122
if (user.getGivenName() != null && user.getGivenName().length() > 255) {
throw new InvalidScimResourceException("Given name must be no more than 255 characters in length.");
}
if (user.getFamilyName() != null && user.getFamilyName().length() > 255) {
throw new InvalidScimResourceException("Family name must be no more than 255 characters in length.");
incrementErrorCounts(e);
// User can supply trace=true or just trace (unspecified) to get stack
// traces
boolean trace = request.getParameter("trace") != null && !"false".equals(request.getParameter("trace"));

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, should we remove this trace option? It does not seem the best idea to expose exception stack trace as API response. Maybe adding a traceId to the response that is also logged server side would be the best of both worlds.


@ExceptionHandler
public View handleException(Exception t, HttpServletRequest request) throws ScimException, InternalUserManagementDisabledException {
logger.error("Unhandled exception in SCIM user endpoints. {}", t.getMessage());

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a strange decision - log server side only the exception message, but return to API caller HTTP response with full stack trace. I would prefer the opposite.

@strehle

strehle commented Sep 21, 2026

Copy link
Copy Markdown
Member

@adrianhoelzl-sap is it ready for review ? because of draft status
beside please check comments from reviewers

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Pending Merge | Prioritized

Development

Successfully merging this pull request may close these issues.

5 participants