Security issues if I use a encrypted value as a Query string that I send to users and then decrypt the value and validate on link click?

A "magic link" or one-time token approach does not truly authenticate the individual at the keyboard—it merely assumes that whoever possesses access to the email inbox is the intended user.

Depending on the classification of the data being exposed, that assumption may introduce significant risk:

Sensitive Data (PII, Financial, HIPAA / Protected Health Information, Internal Business Records):

A link in an email is never sufficient. An email can be forwarded, opened on a shared terminal, or accessed via an unauthenticated mobile device. In these scenarios, the link should simply be a navigation shortcut that directs the user to an authentication challenge requiring them to present credentials (and ideally MFA) before an authorized session is established.

Low-Risk / Ephemeral Data (e.g., unsubscribing from a newsletter, confirming an email address, public survey):

A time-limited, single-use cryptographically random token (hashed in the database) is acceptable because unauthorized access carries negligible risk.

Before choosing between an encrypted parameter, a magic link, or a standard login, your first architectural decision must be based on data sensitivity and compliance requirements. If the data must remain confidential to that specific human being, the application must require formal authentication.

Hi @Jerry ,

Encrypting the value works technically, but the bigger issue is that the link itself becomes a credential. Anyone who ends up with the URL can use it, so it's better to design around that than to rely on the encryption.

Risks with an encrypted static ID in a query string

1. Link leakage / reuse: the link can be forwarded, sit in browser history, or be shared. Anyone can click it. No interception needed.
2. No expiration: encrypting a static user ID produces a token that stays valid as long as the key does, and you can't revoke it.
3. URLs get logged: query strings show up in proxy and web server logs, browser history and cache, and can leak through the Referer header when the page links out. HTTPS doesn't help with any of that.

Safer approach

1. Use a one-time random token instead of an encrypted ID. Generate a cryptographically secure random value, store a hash of it in your database with the user ID and an expiry (an hour is a reasonable starting point for an emailed link). On click, hash the incoming value, look it up, and invalidate after use. Storing the hash rather than the raw token means a database leak doesn't hand over working links.
2. Exchange the token for a session on first click. Validate it, set the auth cookie, then redirect to a clean URL with no token. Without this, a single-use token breaks on page refresh, and the token stays in browser history and the Referer header.
3. Still authorize on every request afterward. The token only proves identity at click time. Your queries should filter by the resolved user ID so one user can never pull another's data, even if a token is misused.
4. Don't write your own AES code. On ASP.NET Core, use the Data Protection APIs — a tampered value fails on Unprotect with a CryptographicException instead of decrypting into someone else: Get started with the Data Protection APIs. If you're on .NET Framework, Data Protection is the documented replacement for <machineKey>.

If you want to stay stateless, ITime LimitedDataProtector gives you expiry built in — the docs use a one-hour password reset token as the example, which is close to your scenario: Limit the lifetime of protected payloads. That gets you expiration but not revocation, so it's a trade-off.

One note: plain JWTs aren't a good fit here. They're signed, not encrypted, so the user ID is readable straight out of the URL — which defeats the reason for encrypting in the first place. You'd need JWE for that.

To your actual question: no, one user shouldn't be able to see another's data, but that comes from a server-side authorization check, not from the encryption. If the data is sensitive (financial, health, PII), consider a second check on the landing page so the link alone .

If you found my response helpful or informative, I would greatly appreciate it if you could follow this guidance or provide feedback.

Thank you.

I'm looking into this post and will get back to you soon. Thank you for your patience.

this is pretty common approach, but you typically also add a time limit. email is not the most secure deliver method, so you mitigate by not allow the link a long life.