DEV Community: Mayank Jain

Before you connect that MCP server, run these three commands

Mayank Jain — Mon, 07 Sep 2026 16:50:31 +0000

MCP servers are appearing faster than anyone can vet them. Your editor offers connectors. Claude and ChatGPT have directories. Someone on your team will wire one into a work account this week, and the flow is designed to take about four seconds: click Connect, approve, done.

Here's what those four seconds actually decide — and three commands you can run first.

What you're granting, stated plainly

When you connect an MCP server, you are letting a language model call functions on your behalf, in your account, with your permissions, based on its interpretation of sentences typed in a chat box.

That's not an argument against doing it. It's an argument for knowing three things before you do:

What can it do? Not "what will it do" — models are probabilistic and prompts get injected. What is the worst thing the exposed tools make possible?
How is it authenticating? A pasted API key that never expires is a very different risk from a one-hour OAuth token you can revoke.
What happens when you disconnect? If a key still works afterwards, you didn't disconnect anything.

Most connector UIs answer none of these. But a well-built MCP server publishes enough to answer #2 yourself, before you click anything.

Check 1: what is this server asking for?

Servers that implement the spec properly expose OAuth metadata at a well-known path, and it's readable without any credentials:

curl -s https://example.com/.well-known/oauth-protected-resource/mcp | jq

Real output from a server that does this correctly:

{
  "resource": "https://webcuris.com/mcp",
  "authorization_servers": ["https://webcuris.com"],
  "scopes_supported": ["mcp"],
  "bearer_methods_supported": ["header"],
  "resource_documentation": "https://webcuris.com/docs/mcp"
}

What you're reading for:

authorization_servers — where you'll actually be typing your password. If it isn't the vendor's own domain, stop.
scopes_supported — a short, specific list is a good sign. A scope like full_access tells you the model has no scoping.
resource_documentation — a server that links its own docs has usually thought about being audited.

Nothing at that path? Not automatically damning, but it means the server isn't following the discovery spec, and you're now trusting a UI's summary instead of the server's own declaration.

Check 2: does it actually require authentication?

This one is quick and occasionally alarming:

curl -s -o /dev/null -w '%{http_code}\n' -X POST https://example.com/mcp \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

You want 401.

If an unauthenticated tools/list returns the tool list, the server is happy to talk to strangers. That may be intentional for a public read-only server — but if it's a server that touches your data, it means authentication was bolted on somewhere other than the front door, and you should want to know where.

Check 3: does it point you at the right place?

A correct 401 doesn't just refuse — it tells the client where to authenticate:

curl -sD - -o /dev/null -X POST https://example.com/mcp \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' \
  | grep -i www-authenticate

www-authenticate: Bearer realm="Webcuris MCP",
  resource_metadata="https://webcuris.com/.well-known/oauth-protected-resource/mcp"

That header is how a client discovers where to get a token without you pasting anything. Its presence means the server implements the flow rather than improvising it — and improvised auth is where the interesting bugs live.

The one thing to read on the consent screen

When the approval page appears, most people read the app name and click. Read one more thing: the redirect address your browser will be sent back to.

That's the field that decides where your authorization code lands. A consent screen that doesn't show it is asking you to approve something you can't see, and a mismatched one is the classic way codes get stolen.

After you connect: ask it what it can do

Once connected, before you use it for anything real, ask the assistant directly:

"List every tool you have available from this connector, and what each one does."

Then read the list as an attacker would. For each tool, finish this sentence: "the worst plausible outcome of the model calling this at the wrong moment is…"

If any answer is worse than "a wasted API call", you've found the thing to think about. Tools that create, delete, send, pay, or invite deserve more scrutiny than tools that read.

If you're building one

Same list, from the other side:

Publish the metadata. Let people audit you before they trust you.
Return 401 with WWW-Authenticate. It's the spec, and it's how clients find your auth without a human pasting secrets.
Keep the tool surface small and boring. Every administrative endpoint you expose is a sentence away from being called.
Call the same code your UI calls. A parallel API written for assistants will reimplement 90% of your authorization checks. The missing 10% is the incident.
Make Disconnect mean something. Short tokens, rotation, and revocation that takes effect on the next request rather than the next cache expiry.

The short version

The MCP ecosystem is about a year old and the conventions are being set right now by whoever ships first. That's exciting, and it means the usual safety rails — app store review, years of hardening, well-known bad actors — mostly don't exist yet.

Three curl commands is a low bar. But it's a much higher bar than clicking Connect, which is what most people are doing.

Disclosure: I work on Webcuris, which has an MCP server — the real output above is from ours, because it's the one I can show you without picking on somebody. The checks work on any server.

Find your own dangling subdomains before someone else does

Mayank Jain — Wed, 02 Sep 2026 14:15:18 +0000

Here's a bug that costs an attacker nothing to find and costs you your domain's reputation.

Someone on your team points a subdomain at a cloud service. One DNS line: promo.yourcompany.com CNAME yourcompany.pages-host.io
Months later the cloud account gets deleted. The DNS record does not.
That CNAME now points at a name on someone else's platform that belongs to nobody — until a stranger registers it.

From that moment they publish whatever they like, on your subdomain, with your certificate and your reputation. It's called subdomain takeover, and the reason it keeps happening is that every step is something a competent team does on a normal day.

Let's find yours. Everything below runs locally, reads only public data, and takes about a minute.

Step 1: enumerate subdomains you've forgotten

You can't audit what you can't list, and the DNS zone in your provider's UI is only the records that still exist — not the historical ones you should be looking for.

The trick is certificate transparency logs: every TLS certificate ever issued is published to a public, append-only log. If a subdomain ever had HTTPS, it's in there. crt.sh makes that queryable:

curl -s "https://crt.sh/?q=%25.example.com&output=json" \
  | jq -r '.[].name_value' \
  | sed 's/^\*\.//' \
  | sort -u

Expect surprises. This routinely surfaces staging hosts, an old marketing subdomain, and a service someone trialled in 2022.

Step 2: find the CNAMEs

Dangling records are almost always CNAMEs — a record pointing at a name on someone else's infrastructure, rather than an IP you control.

dig +short CNAME promo.example.com

Empty output means it isn't a CNAME, so it isn't this class of bug. Skip it.

Step 3: check whether the target still exists

This is the actual test. If the CNAME target resolves to nothing, the record is dangling:

dig +short A yourcompany.pages-host.io
dig +short CNAME yourcompany.pages-host.io

Both empty → nobody is answering for that name. On a platform that lets anyone register an unused project name, that's a claimable takeover.

Putting it together

#!/usr/bin/env bash
# Find dangling CNAME records on a domain.
# Usage: ./dangling.sh example.com
set -euo pipefail
domain="${1:?usage: $0 example.com}"

curl -s "https://crt.sh/?q=%25.${domain}&output=json" \
  | jq -r '.[].name_value' \
  | sed 's/^\*\.//' \
  | sort -u \
  | while read -r host; do
      target=$(dig +short CNAME "$host" | sed 's/\.$//')
      [ -z "$target" ] && continue

      if [ -z "$(dig +short A "$target")" ] && [ -z "$(dig +short CNAME "$target")" ]; then
        echo "DANGLING   $host  ->  $target"
      else
        echo "ok         $host  ->  $target"
      fi
    done

Needs curl, jq and dig. Output looks like:

ok         www.example.com  ->  example.com
DANGLING   promo.example.com  ->  example.pages-host.io

Anything on a DANGLING line is a live issue. Delete the DNS record — that's the whole fix. If you still need the subdomain, re-create the service first and point the record at something you actually control.

Why this deserves more attention than it gets

Two things make subdomain takeover nastier than its low profile suggests.

It defeats the one rule users are taught. "Check the URL before you enter your password" fails completely here, because the URL is real. A phishing page on your own subdomain passes the exact check people are trained to trust — and if any of your cookies are scoped to .yourcompany.com, they may be readable from it too.

Nobody is targeting you. Attackers run this exact scan across millions of domains continuously and harvest whatever falls out. Your forgotten subdomain isn't found because someone was hunting you; it's found because someone was hunting everyone.

The habit worth forming

Most security advice is about doing something. This one is about un-doing — the records, accounts and endpoints that were fine when created and became dangerous only through neglect.

Run the script. Then put a calendar reminder to run it again next quarter, because the zone you clean today grows a new loose end the next time someone needs a landing page in a hurry.

Disclosure: I work on Webcuris, which maps exposed and dangling subdomains as part of a scan. But the script above is the same check, and it's yours — no account needed.

Originally published at webcuris.com.

What your site tells a stranger before it renders a single pixel

Mayank Jain — Mon, 31 Aug 2026 14:08:24 +0000

Type a domain, hit enter, and before anything paints, your server and the browser have already had a short conversation. The server sends back response headers — and to anyone who knows how to read them, those headers are a fairly candid statement about how seriously that site takes its own security.

Attackers read them first. Not because headers are exciting, but because they're free: no login, no exploit, nothing in your logs. One request tells them whether you're worth more attention.

Let's read them the way they do. Open devtools → Network → reload → click the first request → Response Headers. Follow along on your own site.

1. `Strict-Transport-Security` — does your HTTPS actually mean anything?

You have a cert. The padlock shows. But think about what happens when someone types your domain without the scheme — which is everyone:

GET http://yourdomain.com     ← plaintext, before your redirect exists
301 → https://yourdomain.com  ← too late for that first hop

On a hostile network, an attacker in the middle can intercept that first request and simply never deliver your redirect, keeping the victim on plaintext they won't notice.

HSTS fixes it by telling the browser: for the next N seconds, never contact this host over HTTP at all.

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Reading it: no header → every first visit is interceptable. A max-age far under a year is a weak commitment. No includeSubDomains → protection stops at the apex. HTTP Archive's 2025 crawl found HSTS on about 36% of pages.

2. `Content-Security-Policy` — what happens when something does get injected?

The most consequential header, and the least deployed. CSP tells the browser which sources of script are allowed to execute. Anything else — an injected <script> from a comment field, a compromised third-party widget, a supply-chain hit on a dependency — the browser refuses to run.

Its absence isn't a vulnerability by itself. It's the absence of the safety net under every other mistake you might make. With a solid CSP, an XSS bug is often an annoyance. Without one, the same bug owns the page.

Same crawl: only 21.9% of sites send a CSP at all.

# what you want (nonce-based)
Content-Security-Policy: script-src 'nonce-{random}' 'strict-dynamic'; object-src 'none'; base-uri 'none'

# what mostly gets shipped
Content-Security-Policy: script-src 'self' 'unsafe-inline'

Reading it: 'unsafe-inline' in script-src substantially undoes the protection — it permits exactly the inline execution injection relies on. A nonce or hash policy is the real thing. It's more work, which is why it's rarer.

One warning from our own production, since I've now paid for this lesson: if you go nonce-based on Next.js App Router, make sure every interactive page renders dynamically. A statically prerendered page has no request, so it gets no nonce, so the browser blocks every script on it. Dev never shows this — next dev renders everything dynamically.

3. `Set-Cookie` — how carefully is the session handled?

Your session cookie is the logged-in user. Three attributes decide how hard it is to steal:

Set-Cookie: session=…; HttpOnly; Secure; SameSite=Lax; Path=/

HttpOnly — JavaScript can't read it. Without this, any script injection exfiltrates sessions directly.
Secure — never sent over plaintext.
SameSite — restricts cross-site sending; the core CSRF defence.

Reading it: a session cookie without HttpOnly tells an attacker that one XSS gets them accounts, not just defacement.

4. `Server` / `X-Powered-By` — what exactly are you running?

Plenty of stacks announce their software and version by default:

Server: Apache/2.4.41
X-Powered-By: PHP/7.4.3

That's a shortcut: instead of probing, they look up known vulnerabilities for that exact build. Removing these isn't a real defence — a determined attacker fingerprints you anyway — but publishing them narrows their work from hours to seconds, and a version string also announces, at a glance, whether you're years behind.

The meta-signal

Here's the part that matters more than any single header. Someone reading your response isn't only collecting weaknesses — they're forming a judgement about the people who run this site. These headers are cheap; most are one line of config. A site with HSTS, a real CSP and properly flagged cookies says someone here thought about this, and probably thought about the harder things too. A site with none of them says the opposite, before any deeper probing begins.

Your five-minute checklist

Devtools open, first request selected, four questions:

Is Strict-Transport-Security present, with a long max-age?
Is there a Content-Security-Policy — and does it avoid unsafe-inline for scripts?
Does the session cookie carry HttpOnly, Secure and SameSite?
Are you advertising exact software versions you don't need to?

Whatever you find is the same thing a stranger sees on their first request. The only difference is that they've already looked.

Disclosure: I work on Webcuris — these headers are among the first things we read on a scan, along with TLS, email auth and exposed subdomains. But you don't need us for the checklist above; the devtools you already have will answer all four questions.

Originally published at webcuris.com.

[Boost]

Mayank Jain — Fri, 28 Aug 2026 17:13:18 +0000

Mayank Jain

Aug 27

The CSP that killed our own form (a production-only Next.js bug)

#security #debugging #nextjs #webdev

5 min read

The CSP that killed our own form (a production-only Next.js bug)

Mayank Jain — Thu, 27 Aug 2026 09:21:18 +0000

A user wrote to us with the kind of bug report that makes your stomach drop:

"The forgot-password form is not working at all."

Not "it's slow." Not "I got an error." Not working at all.

So we did what you do. Checked the error tracker: clean. Checked the server logs: clean. Checked the audit log that records every password-reset request: zero requests, ever. The endpoint worked perfectly from curl. The page returned a healthy 200. Every test in a 3,500-test suite was green.

And the form was completely dead in production.

Here's the story of why — and why this class of bug is invisible in development, invisible in CI, and invisible to every server-side monitor you own.

The setup: a CSP we were proud of

Our site ships a strict Content-Security-Policy. No unsafe-inline for scripts — instead, every response gets a fresh cryptographic nonce, stamped into the header by middleware:

export function middleware(request: NextRequest) {
  const nonce = Buffer.from(crypto.randomUUID()).toString("base64");
  const csp = buildCsp(nonce); // script-src 'nonce-...' 'strict-dynamic' ...

  const headers = new Headers(request.headers);
  headers.set("x-nonce", nonce);
  headers.set("content-security-policy", csp);

  const response = NextResponse.next({ request: { headers } });
  response.headers.set("content-security-policy", csp);
  return response;
}

Next.js plays along beautifully: it reads the nonce out of the script-src directive and stamps it onto every script tag it injects for hydration. Browser sees matching nonces, scripts run, page hydrates. This is the textbook setup — a security-scanner company can hardly ship unsafe-inline.

There is just one sentence in the fine print, and it bit us:

Next.js only injects the nonce on pages that are rendered dynamically — per request.

The trap: one page quietly went static

In the Next.js App Router, pages that don't read request-time data get statically prerendered at build time. That's normally a gift: free speed. You can see which is which in the build output:

├ ○ /forgot-password      ← static  (prerendered at build time)
├ ƒ /login                ← dynamic (rendered per request)
├ ƒ /reset-password       ← dynamic

See it? Our /forgot-password page — a page with a form, a bot-check widget, client-side validation — was the one interactive page in the whole build that went static. Its HTML was baked once at build time. And at build time, there is no request, so there is no nonce.

Result: the page shipped script tags with no nonce at all, into responses whose CSP header demanded one.

The browser did exactly what we had asked it to do:

Refused to execute script '.../_next/static/chunks/main-app.js'
because it violates the following Content Security Policy directive: ...
Refused to execute script '.../_next/static/chunks/app/layout.js' ...
Refused to execute script ... (× every single chunk)

*Every script on the page: blocked. By our own security header.
*

Why "not working at all" was the perfect description

With zero JavaScript executing:

React never hydrated. No component ever mounted.
The bot-check widget never rendered. It's loaded by script.
The submit handler never attached. So the button fell back to what a button inside a does natively: submit-and-reload. Click → page flickers → same page. To a user, that is precisely "not working at all."
No request ever left the browser. Which is why every server-side signal we had — logs, error tracker, audit trail — was spotless. You cannot log a request that was never made.

And the cruelest part:

next dev renders everything dynamically. The bug cannot exist in development.
curl doesn't execute JavaScript. The page 200s all day.
Unit tests don't run a browser against the production build with the production CSP.
The only place this bug existed was the one place we weren't looking: a real browser, pointed at the production build, with the console open.

The two-minute diagnosis (once we looked in the right place)

Opening the production page with DevTools showed a wall of red CSP violations. Then one comparison nailed it — count nonced scripts per page:

// in the console, on each page:
[...document.scripts].filter(s => s.nonce).length
// /login:            15  ✅
// /pricing:          19  ✅
// /forgot-password:   0  ❌  ← there's your dead page

Cross-checked against the build route table: /forgot-password had the ○ (static) marker. Its sibling /reset-password was dynamic — because someone had once added the magic line there and not on the twin page.

The fix: one line, plus the part that actually matters

The one line:

// app/forgot-password/page.tsx

// Under a nonce CSP, a statically prerendered page ships un-nonced
// scripts and the browser blocks all of them. This line is load-bearing.
export const dynamic = "force-dynamic";

Rebuild: ○ becomes ƒ, nonces flow, widget renders, form lives.

But a one-line fix for a silent, production-only, whole-page failure deserves more than one line. Two things we added:

*1. A regression test that names the failure class, not the instance:
*

describe("no auth page may be statically prerendered", () => {
  // Under a nonce CSP, a static page is a dead form waiting
  // for a user to find it.
  for (const page of ["login", "signup", "forgot-password", "reset-password"]) {
    it(`${page} forces dynamic rendering`, () => {
      const source = readFileSync(`app/(auth)/${page}/page.tsx`, "utf-8");
      expect(source).toContain(`export const dynamic = "force-dynamic"`);
    });
  }
});

2. A QA rule we now follow on every release: at least one pass through the production deployment, in a real browser, with the console open. A page can return 200, look pixel-perfect, and be completely dead. Your server cannot tell you about requests that never happen — only the browser knows.

Takeaways

Your security controls are part of your attack surface — against yourself. A strict CSP is worth it, but every hardening measure needs a test that proves the product still works under it.
Static vs. dynamic rendering is a security-relevant decision in the App Router, not just a performance one. If your CSP uses nonces, an interactive page that goes static is broken by construction.
Absence of errors is not evidence of health. Every monitoring signal we had was green while 100% of users hit a dead form. The failure lived client-side, before the first request.
Read your build output. That little ○/ƒ column is a security audit nobody performs.

We build Webcuris(https://webcuris.com/) — continuous security assessment for websites and repos: CSP, TLS, headers, dependencies, and whether last month's fix actually held. This bug shipped in our own product, which is exactly why we believe in re-checking everything, continuously. You can scan one page free, no signup. (https://webcuris.com/scan)

DEV Community: Mayank Jain

Before you connect that MCP server, run these three commands

What you're granting, stated plainly

Check 1: what is this server asking for?

Check 2: does it actually require authentication?

Check 3: does it point you at the right place?

The one thing to read on the consent screen

After you connect: ask it what it can do

If you're building one

The short version

Find your own dangling subdomains before someone else does

Step 1: enumerate subdomains you've forgotten

Step 2: find the CNAMEs

Step 3: check whether the target still exists

Putting it together

Why this deserves more attention than it gets

The habit worth forming

What your site tells a stranger before it renders a single pixel

1. Strict-Transport-Security — does your HTTPS actually mean anything?

2. Content-Security-Policy — what happens when something does get injected?

3. Set-Cookie — how carefully is the session handled?

4. Server / X-Powered-By — what exactly are you running?

The meta-signal

Your five-minute checklist

[Boost]

The CSP that killed our own form (a production-only Next.js bug)

The CSP that killed our own form (a production-only Next.js bug)

The setup: a CSP we were proud of

The trap: one page quietly went static

Why "not working at all" was the perfect description

The two-minute diagnosis (once we looked in the right place)

The fix: one line, plus the part that actually matters

Takeaways

1. `Strict-Transport-Security` — does your HTTPS actually mean anything?

2. `Content-Security-Policy` — what happens when something does get injected?

3. `Set-Cookie` — how carefully is the session handled?

4. `Server` / `X-Powered-By` — what exactly are you running?