Activity

1. rartych

   added a parent issue on Sep 8, 2026

   • Release r3.1 review findings #213
2. stroncoso

   added the

   Task

   issue type on Sep 21, 2026
3. stroncoso

   self-assigned this

   on Sep 21, 2026
4. stroncoso commented on Sep 21, 2026

   

   stroncoso

   on Sep 21, 2026

   Contributor

   More actions

   Taking a deep look to get a complete table and potential patterns to use and share with the team...
5. stroncoso commented on Oct 6, 2026

   

   stroncoso

   on Oct 6, 2026

   Contributor

   More actions

   S-313 string constraints (issue #219)

   • I was analysing the string usage and potential regex to validate them.
   • Find on this table the suggested + some examples that will work or not.
   • If the team agrees, I can submit the PR for that.
   • The main thing to confirm is if we should close thigh the free-text fields, or be more permissive. Some examples to feed your mind:
     • Should a name include symbols? "alice" <a@x.id> is allowed right now...
     • Should a description include change of lines and similar?

   @teikuran , @deepakjaiswal1 , take a look, or we can discuss it on the WebRTC meeting session.

   Thanks in advance!

     -- 🤖 LLM content ahead --
   

   Rule S-313 (owasp:api4:2023-string-restricted): Schema of type string should specify a format, pattern, enum, or const.

   All affected strings already satisfy S-312 (maxLength). The proposal below adds a pattern or enum to each one, as a base security limit against injection.

   Affected strings

   #	Field	Location(s) (file:line)	Definition	Current constraint	Example	Suggested S-313 adaptation
   1	registrationId	call-handling hdrRegistrationId :464 (header) registration pathParamRegistrationId :467 (path) registration RegSessionResponse.registrationId :557 events RegistrationId :838	Device registration identifier assigned by the network (registration service). Clients must use it as a parameter in the call-handling and subscription APIs.	maxLength: 256	ln3C-ttOSk-ObcQ7A0-tYO1LXqy xsmcaum3z4zw4l0cu4w115m0 a1b2c3d4-1234-5678-abcd-ef0123456789	pattern (opaque, URL-safe, RFC 3986 unreserved): ^[A-Za-z0-9._~-]{1,256}$ Define once as shared RegistrationId schema and $ref it from all 4 places.
   2	mediaSessionId	call-handling pathParamMediaSessionId :474 (path) call-handling MediaSessionResponse.mediaSessionId :550 events MediaSession.mediaSessionId :964	Media session ID created by the network. Not sent by the client in POST; must be included in notifications from network to client.	maxLength: 256	0AEE1B58BAEEDA3EABA42B32EBB3DFE07E9CFF402EAF9EED8EF	pattern (opaque, URL-safe, RFC 3986 unreserved): ^[A-Za-z0-9._~-]{1,256}$ Define once as shared MediaSessionId schema and $ref it from all 3 places.
   3	originatorName	call-handling MediaSessionInformation :496 events MediaSession :922	Friendly name of the call originator	maxLength: 256	Alice	pattern (free text, no control / bidi / zero-width chars): ^[^\x00-\x1F\x7F-\x9F​-‏‪-‮⁦-⁩]{1,256}$ See Display names: symbols and URI-like content.
   4	receiverName	call-handling MediaSessionInformation :503 events MediaSession :933	Friendly name of the call terminator	maxLength: 256	Bob	Same as #3.
   5	sdp	call-handling WrtcSdpDescriptor.sdp :583 events WrtcSdpDescriptor.sdp :1008	Inlined session description in SDP format (RFC 4566).	maxLength: 65536	v=0\r\no=- 4576312012535546667 4 IN IP4 127.0.0.1\r\ns=-\r\nt=0 0\r\n...	pattern (RFC 4566 <type>=<value> lines): ^v=0(\r?\n[a-z]=[^\r\n]*)*\r?\n?$ Requires fixing the truncated examples ( [...]) in call-handling and events.
   6	type (CloudEvent)	events CloudEvent.type :850	Event type of the notification. Used as the discriminator.	maxLength: 512	org.camaraproject.webrtc-events-subscriptions.v0.session-invitation	enum (same 4 values as the discriminator mapping): ...v0.session-invitation ...v0.session-status ...v0.subscription-ended ...v0.registration-ends
   7	reason	events MediaSession.reason :969	Description of the event that happened within the session	maxLength: 2048	New subscriber incoming call	pattern (free text, allows tab/LF/CR): ^[^\x00-\x08\x0B\x0C\x0E-\x1F\x7F]{1,2048}$
   8	terminationDescription	events RegistrationEnds.terminationDescription :1083	Human-readable explanation of why the registration was terminated	maxLength: 2048	SIP re-registration required	Same as #7.

   Pattern behaviour examples

   Results verified with the ECMA-262 regex engine (the one used by OpenAPI/JSON Schema validators).

   Input	ID (#1, #2) ^[A-Za-z0-9._~-]{1,256}$	Name (#3, #4) ^[^\x00-\x1F\x7F-\x9F​-‏‪-‮⁦-⁩]{1,256}$	Free text (#7, #8) ^[^\x00-\x08\x0B\x0C\x0E-\x1F\x7F]{1,2048}$	SDP (#5) ^v=0(\r?\n[a-z]=[^\r\n]*)*\r?\n?$	Notes
   ln3C-ttOSk-ObcQ7A0-tYO1LXqy	✅	✅	✅	❌	Current ID example
   a1b2c3d4-1234-5678-abcd-ef0123456789	✅	✅	✅	❌	UUID-style ID
   abc/../x	❌	✅	✅	❌	Path traversal in path param
   id;DROP TABLE	❌	✅	✅	❌	SQL-like injection
   id%0d%0a	❌	✅	✅	❌	Encoded CRLF
   Alice	✅	✅	✅	❌	Current name example
   José Ñúñez	❌	✅	✅	❌	Accented letters
   O'Brien	❌	✅	✅	❌	Apostrophe
   王小明	❌	✅	✅	❌	Non-Latin script
   Dr. Alice (Sales)	❌	✅	✅	❌	Common punctuation
   Alice & Bob	❌	✅	✅	❌	Symbol
   Bob 📞	❌	✅	✅	❌	Emoji
   Alice\r\nX-Injected: 1	❌	❌	✅	❌	CRLF header injection
   Bob\x00	❌	❌	❌	❌	NUL truncation
   Alice\x1B[31m	❌	❌	❌	❌	Terminal escape sequence
   Bob‮gpj.exe	❌	❌	✅	❌	Bidi override (renders Bobexe.jpg)
   Ali​ce	❌	❌	✅	❌	Zero-width space (lookalike Alice)
   <script>alert(1)</script>	❌	✅	✅	❌	XSS payload
   "Alice" <sip:evil@x.com>	❌	✅	✅	❌	SIP display-name / URI spoofing
   sip:evil@x.com	❌	✅	✅	❌	Bare URI as name
   v=0\r\no=- 1 2 IN IP4 127.0.0.1\r\ns=-\r\nt=0 0\r\n	❌	❌	✅	✅	Valid SDP
   v=0\r\na=mid:audio\r\n [...]	❌	❌	✅	❌	Truncated spec example
   v=0\r\nINVITE sip:x SIP/2.0\r\n	❌	❌	✅	❌	SIP message smuggled in SDP

   Display names: symbols and URI-like content

   Open point: should originatorName / receiverName accept symbols and URI-like content such as "Alice" <sip:evil@x.com>?

   These values may end up as the display name in SIP From/To headers and in caller UIs. Accepting ", < and > allows a name that imitates a full SIP name-addr, which can spoof the caller identity shown to the user or break header quoting if the gateway does not escape it.

   Option	Pattern	Alice & Bob	<script>…	"Alice" <sip:evil@x.com>	sip:evil@x.com	Trade-off
   A. Control chars only	^[^\x00-\x1F\x7F]{1,256}$	✅	✅	✅	✅	Blocks CRLF/NUL/ESC only. Bidi and zero-width spoofing pass.
   B. A + bidi/zero-width (current proposal)	^[^\x00-\x1F\x7F-\x9F​-‏‪-‮⁦-⁩]{1,256}$	✅	✅	✅	✅	Adds protection against visual spoofing. Symbols and URIs still pass.
   C. B + no " < >	^[^\x00-\x1F\x7F-\x9F​-‏‪-‮⁦-⁩"<>]{1,256}$	✅	❌	❌	✅	Blocks name-addr imitation and HTML tags. Bare URIs still pass; blocking : or @ would also reject legitimate names.
   D. Unicode allowlist	^[\p{L}\p{M}\p{N} .,'()\-]{1,256}$	❌	❌	❌	❌	Strictest. Rejects &, emoji and other symbols. Needs the regex u flag, which OpenAPI tools support inconsistently.

   Whatever the option, the field description should state that implementations MUST escape the value for its output context (SIP header quoting, HTML), since no pattern replaces output encoding.
6. teikuran commented on Oct 7, 2026

   

   teikuran

   on Oct 7, 2026

   Contributor

   More actions

   @stroncoso
   According to Section 2.2 of the CAMARA API Design Guide, "If the data type is string, maxLength property or enum construct MUST be used to constrain values." It also states, "If the data type is string it is RECOMMENDED to use the appropriate modifier property format and/or pattern whenever possible."

   My understanding is therefore that maxLength (or enum) is the mandatory requirement, while adding format and/or pattern is recommended where an appropriate constraint can be defined.

   For the S-313 findings where maxLength is already specified, it seems that the mandatory requirement in Section 2.2 is already satisfied. Therefore, I am not sure that we need to introduce a pattern simply to clear every S-313 warning. I am not saying that we do not need to study those findinds - but are they urgent for this release?
7. rartych commented on Oct 7, 2026

   

   rartych

   on Oct 7, 2026 via email

   CollaboratorAuthor

   More actions

   Hi Tsuyoshi, You are right. The warning is to just consider pattern/format, but not every string can have reasonable pattern/format. So just review the parameters, and do not care about pending S-313. Regards, Rafal From: tsuyoshi takakura ***@***.***> Sent: Wednesday, October 7, 2026 3:17 AM To: camaraproject/WebRTC ***@***.***> Cc: Artych Rafał ***@***.***>; Author ***@***.***> Subject: Re: [camaraproject/WebRTC] String has no format/pattern/enum (Issue #219) SECURITY WARNING: Ta wiadomość pochodzi z zewnętrznego źródła - uważaj na załączniki i linki. Jeśli wiadomość wyda Ci się podejrzana zgłoś incydent. This email is from an external source - be careful of attachments and links. Please follow good practices and report suspicious emails. [Image removed by sender.]teikuran left a comment (camaraproject/WebRTC#219)<#219 (comment)> @stroncoso<https://github.com/stroncoso> According to Section 2.2 of the CAMARA API Design Guide, "If the data type is string, maxLength property or enum construct MUST be used to constrain values." It also states, "If the data type is string it is RECOMMENDED to use the appropriate modifier property format and/or pattern whenever possible." My understanding is therefore that maxLength (or enum) is the mandatory requirement, while adding format and/or pattern is recommended where an appropriate constraint can be defined. For the S-313 findings where maxLength is already specified, it seems that the mandatory requirement in Section 2.2 is already satisfied. Therefore, I am not sure that we need to introduce a pattern simply to clear every S-313 warning. I am not saying that we do not need to study those findinds - but are they urgent for this release? — Reply to this email directly, view it on GitHub<#219?email_source=notifications&email_token=A43QYQPOX4HIXI444ZUEHFL5SWKRTA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTMMBSHA3TOOBYGA3KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-6028778806>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/A43QYQPFA6MQVSGGTP5S2ID5SWKRTAVCNFSNUABFKJSXA33TNF2G64TZHM3DSNZYHAYDCOJQHNEXG43VMU5TKMZZGIYDCNBZHE2KC5QC>. You are receiving this because you authored the thread.Message ID: ***@***.***> T-MOBILE POLSKA S.A. z siedzibą w Warszawie Adres: ul. Marynarska 12, 02-674 Warszawa Zarząd Spółki: Andreas Maierhofer - Prezes Zarządu; Juraj Andráš - Członek Zarządu, Dyrektor ds. Finansowych; Maximiliano Bellassai - Członek Zarządu, Dyrektor ds. Rynku Prywatnego; Jovan Ćetković - Członek Zarządu, Dyrektor ds. Technologii i Innowacji; Dorota Kuprianowicz-Legutko – Członkini Zarządu, Dyrektorka ds. HR, Prawnych i Bezpieczeństwa; Andrzej Malinowski – Członek Zarządu, Dyrektor ds. Rynku Biznesowego. Spółka zarejestrowana w Sądzie Rejonowym dla m.st. Warszawy w Warszawie, XIII Wydział Gospodarczy Krajowego Rejestru Sądowego. KRS 0000391193 | NIP 526-10-40-567 | Regon 011417295 Kapitał zakładowy 711.210.000 złotych, kapitał wpłacony w całości. DUŻE ZMIANY ZACZYNAJĄ SIĘ OD MAŁYCH - CHROŃ PLANETĘ, NIE DRUKUJ TEGO E-MAILA, JEŻELI NIE MUSISZ. Ta wiadomość i jej treść są zastrzeżone w szczegółowym zakresie dostępnym na http://www.t-mobile.pl/stopka This e-mail and its contents are subject to a DISCLAIMER with important RESERVATIONS: see http://www.t-mobile.pl/stopka