The trust boundary
The RFP states the threat directly:
"Enforce catalog integrity. The facilitator is a trust boundary: clients echo the resource block into the payment payload, so a hostile client can attempt to poison the catalog with forged service metadata or a crafted routeTemplate. Implement the spec's soft drop validation and validate routeTemplate including percent decoding before traversal checks."
Read that middle clause again: the metadata that populates the catalog arrives from the client, in the payment payload. Automatic cataloging (#130) is what makes the Bazaar usable, and it is also what makes it attackable. Anyone who can pay can attempt to write to the index.
What has to hold
No seller can be impersonated. A listing must not be able to claim another seller's identity, endpoint or pricing. Decide what binds a listing to its rightful owner and state it in the PR — the payment's payTo is the obvious anchor, since it is signed.
routeTemplate must survive a hostile author. The RFP names the exact failure: percent-decode before traversal checks, not after. %2e%2e%2f is ../ and a validator that checks the raw string first and decodes later will pass it straight through. Decode fully, then validate, and test that specific case.
Soft drop. Invalid metadata is dropped rather than failing the payment. The payment is legitimate; only the listing is bad. Report the drop via EXTENSION-RESPONSES (#130) so the seller learns why.
Also worth covering
- Field-level limits: length, type, allowed characters. An unbounded description field is a storage and a search-ranking problem
- Anything rendered anywhere later — treat catalog content as untrusted at read time too, not only at write
- Rate limiting per
payTo, so one payer cannot flood the index
Acceptance criteria
Drips Wave · Complexity: Advanced · 200 points
Required: Before submitting, join the contributor Telegram so your work can be tracked and counted toward the Stellar Wave: https://t.me/+fxHXq8f1SwlkZDBk
The trust boundary
The RFP states the threat directly:
Read that middle clause again: the metadata that populates the catalog arrives from the client, in the payment payload. Automatic cataloging (#130) is what makes the Bazaar usable, and it is also what makes it attackable. Anyone who can pay can attempt to write to the index.
What has to hold
No seller can be impersonated. A listing must not be able to claim another seller's identity, endpoint or pricing. Decide what binds a listing to its rightful owner and state it in the PR — the payment's
payTois the obvious anchor, since it is signed.routeTemplatemust survive a hostile author. The RFP names the exact failure: percent-decode before traversal checks, not after.%2e%2e%2fis../and a validator that checks the raw string first and decodes later will pass it straight through. Decode fully, then validate, and test that specific case.Soft drop. Invalid metadata is dropped rather than failing the payment. The payment is legitimate; only the listing is bad. Report the drop via
EXTENSION-RESPONSES(#130) so the seller learns why.Also worth covering
payTo, so one payer cannot flood the indexAcceptance criteria
routeTemplateis percent-decoded before traversal validation, with an explicit%2e%2e%2ftest caseEXTENSION-RESPONSESsays whypayTorate limiting on catalog writesRequired: Before submitting, join the contributor Telegram so your work can be tracked and counted toward the Stellar Wave: https://t.me/+fxHXq8f1SwlkZDBk