validation(schemas): reject control characters in persisted names - #1089
validation(schemas): reject control characters in persisted names#1089seonghobae wants to merge 5 commits into
Conversation
This commit adds explicit regex validation to the DiagramViewCreateIn and ApiKeyCreateIn schemas to reject control characters, hardening these fields against log injection or unexpected terminal escapes.
|
👋 Jules, reporting for duty! I'm here to lend a hand with this pull request. When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down. I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job! For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with New to Jules? Learn more at jules.google/docs. For security, I will only act on instructions from the user who triggered this task. |
|
Important Draft PR not reviewedDraft PRs are not automatically reviewed by default.
To automatically review draft PRs, update your CodeRabbit configuration: reviews:
auto_review:
drafts: trueThanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
seonghobae
changed the title
This commit adds explicit regex validation to the DiagramViewCreateIn and ApiKeyCreateIn schemas to reject control characters, hardening these fields against log injection or unexpected terminal escapes.
This commit adds explicit regex validation to the DiagramViewCreateIn and ApiKeyCreateIn schemas to reject control characters, hardening these fields against log injection or unexpected terminal escapes.
1 participant
Current boundary
This is an input-contract hardening change for persisted/user-visible names. It is not classified as a demonstrated MEDIUM vulnerability: this branch does not establish a concrete downstream log-injection, null-byte exploit, terminal-escape execution path, or severity score.
main@8dc746920c12988f082e914879d95e13c96935352eb1608316a5c0532ce460927ca6e99b6a432611backend/app/schemas.py,backend/tests/test_schema_validation.py.jules/sentinel.mdappendix has been restored byte-for-byte to protected authorityContract
DiagramViewCreateIn.nameandApiKeyCreateIn.key_namealready had non-empty and maximum-length bounds. The candidate additionally rejects C0 controls and DEL (U+0000..U+001F,U+007F) before those values become persisted/displayed names. Ordinary spaces and Unicode names remain admitted.The deterministic schema regression covers NUL, tab, LF, CR, ESC and DEL for both fields and a positive Korean/Japanese/space-bearing control. This keeps the repair at the Pydantic admission boundary rather than inferring safety from a later renderer or logger.
Acceptance
Run the repository-native schema/backend suites and all applicable exact-head CI/Security/SAST/CodeQL gates on one unchanged SHA. Preserve the existing length contracts and Unicode acceptance. If a product requirement later needs multiline/tab-bearing names, that is a domain-policy decision and should change the field contract explicitly rather than bypass validation downstream.
Do not restore repository-wide Sentinel doctrine, manufacture security severity without an exploit/threat-model basis, suppress scanners, self-approve, force-push, destructively rebase, or transfer predecessor GREEN. Keep Draft until terminal exact-head evidence and qualifying current-head independent review are present.