DSN private/public

SDKs
1

When we use DSN inside our code-base and git commit the changes, anyone can see the DSN, who ever has access to the repository.

So my question,

Do we need to keep the DSN private in some kind of environment variable or it can be just pasted as a hard-coded value inside the code-base.

1 Like
2

The DSN is not a secret, worst thing someone could do is sending events to your account.
All “analytics” services have this problem.

If that ever happens you have a few options tackling this, you can either block off certain request or cycle the DSN.

So having it in the repo is fine.

1 Like
3

What do you mean by that? You mean allow data event from only specific domains?

I am not aware of this feature, can you share me link to docs for this.

4

So, why don’t you recommend to the users to store their DSN as a variable key or keep it somewhere private. (just curious to ask)

5

You can create just a new DSN and delete old ones. You can find this in your project settings -> Client Keys.

Recommending storing the DSN somewhere private would be conflicting messaging from our side.

Let’s imagine you use @sentry/browser on your website, it’s impossible to hide the DSN in javascript. No one stops you from using the same DSN on your server.

So you see, we can’t make it secret so we don’t tell people it’s a secret, it’s basically an id identifying your account.

2 Likes
6

I understand that some DSN’s have to be public, but I strongly believe that some effort to keep them private is warranted. I’m pushing for a change to documentation to this effect over here if anybody wants to wade in:

(that issue references this forum post as a reason not to encourage private DSNs, so figured I’d link up the circle.)