SendGrid, Twilio, Shopify: the SaaS keys that leak and send mail as you

There's a whole class of leaked key that doesn't drain a bank account or own your cloud, and people underrate it for exactly that reason. It sends things. Email, SMS, orders, refunds. From your domain, on your account, on your bill, with your reputation attached.

A SendGrid key starting with SG.. A Twilio API key SID. A Shopify access token starting shpat_. A Square token. These end up in frontend bundles because a form needed to send a confirmation email or fire off an SMS code, and the fast way to do that was to call the SaaS API straight from the browser. The key rode along, and now it's in the JavaScript anyone can read.

What each one actually unlocks

The damage is specific to the service, and "they can email people as me" sounds mild until you think about what that does to your domain.

The deliverability trap

The SendGrid case deserves its own paragraph, because the second-order damage outlasts the leak. When you set up SendGrid, Mailgun, or Brevo, you authorize them to send on behalf of your domain. Your SPF record lists them. Your DMARC says their mail is legitimate. That's correct, and it's what makes your real email land in inboxes instead of spam.

Now a stranger has the sending key. Their phishing email goes out through your verified sender, passes the SPF and DMARC checks you set up, and lands in the inbox looking exactly like you, because as far as the receiving server is concerned, it is you. When recipients report it, the mailbox providers don't blame the attacker. They lower your domain's reputation. You spend the next month watching legitimate invoices and password resets land in spam, fixing a problem you didn't cause but did leave the door open for.

How they leak, and the one fix

Same story as every other secret. A client-side fetch needed an Authorization header, the key got hardcoded or pulled from a NEXT_PUBLIC_/VITE_ env var, and the bundler wrote the literal string into the JavaScript. None of these services offer a browser-safe key, because there's no such thing as a public key that's allowed to send mail or charge cards.

The fix is to put the call behind your own endpoint. The browser posts to your server, your server holds the key and talks to SendGrid or Twilio or Shopify, and the key never enters a file the public can read.

// client form handler, ships to every visitor
await fetch("https://api.sendgrid.com/v3/mail/send", {
headers: { Authorization: "Bearer SG.aBcD...wXyZ" },
// ^ this string is downloadable by anyone
body: JSON.stringify({ to, subject, content }),
});

Then rotate the leaked key, because public once means public forever, and scope the replacement down: a SendGrid key can be restricted to "mail send" only, a Shopify token to the few scopes it actually uses. A leaked key that can only do one narrow thing is a smaller fire than one that can do everything.

Whether an SG., shpat_, Twilio, or Square key is in your shipped JavaScript is something a stranger can read from outside, and so can we. SurfaceCheckr fetches your pages and scripts and scans them for the SaaS key formats these providers use, and flags the page where one is exposed. We can't see your SendGrid logs or whether your domain reputation has already taken a hit, only that the key is readable, which is the thing you want to know before the phishing run, not after.