Hi there. I’m wondering about security in sending traces from the frontend to the backend. Couldn’t anyone send traces to the backend to try and make a DDOS attack. Is the collector built with this in mind? Is there an approach to ensure only authorized applications can send trace, log and metrics to the collector?

There’s already an issue open for this. You can follow it: https://github.com/SigNoz/signoz/issues/1254 cc: @Ankit Nayan Will this be prioritized in upcoming weeks?

Hi @Vishal Sharma Thanks for the reply I was think more about telemetry coming from web browsers. I think the article link in the issue https://medium.com/opentelemetry/securing-your-opentelemetry-collector-1a4f9fa5bd6f is for an OTel agent connecting to with the collector. I would expect that viable within a k8s cluster, but not so viable for web browsers

@Marc d'Entremont great that you brought that up. What security measures you think should be added to enable safe frontend to otel-collector communication? A few in mind are: • Client Authorisation using API_KEY • HTTPS • CSRF protection • CORS handling

I think those approaches to security are the best we can do. I have SigNoz working locally at this point, but I’m hoping for a good solution for avoid abuse before looking at deploying on the Internet.

I understand the concerns for adding tracing to browsers as they would be talking to publicly exposed collectors. I think we should be prioritising this and pick up very soon. Till then you can keep exploring SigNoz without exposing SigNoz to the internet 🙂

While these measures help, the rouge actors can still act bad. In case of API_KEY/SECRET_KEY they can visit your app and copy the values. I am not sure if there is truly attack free system possible if you want to make it accessible from the public internet.

I’m thinking that one approach could be to buffer traces, logs, metrics in the browser until the user authenticates. I know that this would not be appropriate for some web apps, e.g. where user’s do not login, but in many cases it seems like a good approach. In scenarios where a user has a cookie already set it would not need to be buffered, but in reality a little buffering is likely a good thing. There would need to be limits placed to avoid buffering too much data and either a rolling window of data to remove the oldest data as the buffer becomes full, or stop adding data after a certain point.

I think OpenTelemetry sdks already do have buffers to batch data and send but that is unrelated to auth atleast in their case