Skip to content

Add note that DSN can be public #1723

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed

Add note that DSN can be public #1723

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions src/collections/_documentation/error-reporting/configuration/index.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -24,6 +24,9 @@ events.

In runtimes without a process environment (such as the browser) that fallback does not apply.

The DSN does not need to be kept private. If it is abused, the worst case is that another
application could send events to your account.
Comment on lines +27 to +28
Copy link
Contributor

@PeloWriter PeloWriter Feb 16, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested edit below. As to whether to keep the DSN private, it is a combination of your organization's policies and the SDK that you're using.

Suggested change
The DSN does not need to be kept private. If it is abused, the worst case is that another
application could send events to your account.
The DSN does not need to be kept private. If it is abused, you can generate a new DSN by navigating to Settings > Projects > Client Keys (DSN).

Copy link
Contributor

@PeloWriter PeloWriter Feb 16, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For more info, you can also review this posting - https://forum.sentry.io/t/dsn-private-public/6297

Copy link
Contributor Author

@mlissner mlissner Feb 17, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't like how that forum post is framing this as a binary thing. There are shades of gray between fully public and fully private. After my experience, I'd strongly suggest that the policy should be something like, "The DSN should be kept private to the extent possible."

I agree that the worst case is that somebody can send a message to Sentry, but I don't think folks realize just how bad that can be. In our case, it was terrifying and sent our organization into a tailspin until we could figure out what was going on.

I'd also note that it's possible to have different levels of privacy for different DSNs. For example, the ones that are in your JavaScript can be expected to have the occasional false message from an abuser, and your back end can be set up with a different DSN that's kept totally private.

This kind of documentation would have helped us a lot and isn't that hard to understand.


{:.config-key}
### `debug`

Expand Down