Skip to content
This repository was archived by the owner on May 23, 2023. It is now read-only.
This repository was archived by the owner on May 23, 2023. It is now read-only.

Opt-in vs Opt-out & security on propagation at the system boundaries #68

@cwe1ss

Description

@cwe1ss

What's the recommended practice for the following scenarios:

  • someone makes a request to my public webserver and includes fake trace headers. It might even contain fake baggage that would be propagated within my system. I can't just not implement extract-functionality because I might use an OpenTracing enabled load balancer in front of it etc.
  • an internal application sends a http request to some 3rd party system. How do I make sure I don't send my trace headers/baggage here?

In other words, who is responsible for making sure that headers are validated for its boundaries? AFAIK an application developer does not have a way to manipulate spans through the OpenTracing API. Also, hoping that a tracer might offer this functionality seems troublesome - especially when you want to switch tracers.

Or is this an additional out-of-scope hook that must be provided by the http library / web framework? E.g. they will manage their own whitelist/blacklist and just not call inject/extract if it matches.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions