DEV Community: Faraz Ahmad

A PHP Patch Is a Deployment Claim. Here Is How to Prove It.

Faraz Ahmad — Wed, 21 Oct 2026 23:01:15 +0000

A successful package update does not prove that your production requests reach a patched PHP runtime.

The shell may use a different binary from PHP-FPM. A container image may have been rebuilt while an old replica still serves traffic. A second application may live on a host that nobody included in the change.

The useful output of a security change is a chain of evidence connecting the advisory to the code handling real requests. This post proposes a small verification record you can use to make that chain reviewable.

The event that makes this urgent

The PHP project's 21 October 2026 advisory addresses CVE-2026-109618 and CVE-2026-109619. The vulnerabilities can permit unauthenticated remote code execution. The advisory includes PHP installations serving web requests and identifies Apache mod_php as the highest-risk deployment. PHP-FPM should not be assumed immune; exploitability depends on the deployment and application behavior.

The upstream fixed releases for the supported branches are:

Branch	Fixed release for this event
PHP 8.2	8.2.35
PHP 8.3	8.3.36
PHP 8.4	8.4.27
PHP 8.5	8.5.12

A distributor may backport the fixes without changing the displayed upstream version to one of those numbers. Check the complete package revision against that vendor's advisory. Do not label a system vulnerable or fixed from a shortened version string alone.

Use the current official advisory to resolve scope and updates. The record below organizes your deployment evidence; it is not a replacement for the vendor's instructions.

Model the change as four claims

Before choosing commands, decide what you need to establish:

Coverage: The inventory includes each relevant application and serving environment.
Build: The selected artifact or package addresses both CVEs.
Runtime: The intended patched artifact is handling requests across the serving pool.
Behavior: Critical application workflows still complete successfully.

These claims fail independently. Passing three does not make the fourth disappear.

For example, a perfectly verified new runtime can serve an application with broken session behavior. Conversely, a working login does not establish that the runtime contains a security fix.

Create an application-to-runtime record

Start from the public application or service, then work inward. Do not start from a convenient server list and assume it covers everything.

For each application, record the hostname or internal service identifier, environment, responsible operator, deployment method, web runtime, background workers and the source of the deployed artifact.

An illustrative inventory might contain these three rows:

Application	Serving path	Separate check
WordPress marketing site	Managed host with PHP-FPM	Provider's confirmation for the exact application
Laravel customer portal	Load balancer and container replicas	Artifact digest and replacement of every serving replica
Legacy administration tool	Apache host	Actual loaded PHP runtime and vendor support status

These are hypothetical deployments, not client systems. Their purpose is to expose how “we updated PHP” can describe three very different changes.

Include staging environments that hold meaningful credentials or data, secondary nodes and old subdomains. Checking background workers also supports deployment consistency; the advisory’s stated exposure concerns PHP serving web requests. Record an owner for uncertain entries instead of silently dropping them.

Use a small evidence manifest

The following YAML is a documentation template. It is deliberately non-executable and contains no secrets or real infrastructure identifiers.

# Illustrative verification record; replace placeholders with reviewed evidence.
application: example-portal
environment: production
advisories:
  - CVE-2026-109618
  - CVE-2026-109619
owner: ROLE_OR_TEAM
coverage:
  inventory_reference: INTERNAL_RECORD_REFERENCE
  unresolved_environments: []
build:
  vendor_advisory_reference: OFFICIAL_VENDOR_NOTICE
  package_revision_or_image_digest: VERIFIED_IDENTIFIER
  both_cves_addressed: PENDING_VERIFICATION
runtime:
  serving_pool_reference: INTERNAL_POOL_REFERENCE
  evidence_reference: RESTRICTED_EVIDENCE_REFERENCE
  old_instances_removed: PENDING_VERIFICATION
behavior:
  authentication: NOT_TESTED
  form_to_destination: NOT_TESTED
  background_processing: NOT_TESTED
decision:
  technical_acceptance: PENDING
  customer_journey_acceptance: PENDING
  next_review_at: AGREED_CHECKPOINT

Keep sensitive host details and operational evidence in an appropriate restricted system. The manifest can point to that evidence without reproducing it in a public ticket or article.

An empty unresolved list is a claim that needs review. It should never mean “we did not look.”

Verify the web runtime, not only the CLI

CLI output answers a narrow question: which PHP binary did this shell execute?

Your web server may use another installation, a different FPM pool, or a container with a different filesystem. Background workers may survive an application deployment and retain the runtime they started with.

Use your platform's supported inspection methods to connect the running web processes to the patched package or immutable artifact. Record the relevant identity and the time of observation. For a multi-instance service, account for the full serving pool rather than one successful request.

Avoid leaving a public diagnostic endpoint behind. A publicly reachable phpinfo() page can disclose configuration information. Prefer authenticated operational tooling and remove temporary diagnostics through your normal change process.

The StadiaSoft PHP patch verification guide expands the environment-specific questions for managed hosting, PHP-FPM and container deployments.

Distinguish a new artifact from a completed rollout

Suppose an illustrative service has four replicas. The build pipeline produces a patched image, and three replicas are replaced. The rollout reports partial progress while the fourth replica continues serving the old artifact.

The build claim passes. The runtime claim remains open.

Check the deployment controller's view, the instance or pod identities, their artifact references and whether old instances still receive traffic. Update the source build definition too. Otherwise a later deployment can recreate the old base image.

For a managed host, request confirmation tied to the application and environment. “Our platform supports PHP 8.3” gives less useful evidence than a statement identifying the package revision applied to the actual serving pool.

Follow vendor instructions for process replacement and service changes. A generic restart command copied across different hosting environments can create an avoidable outage.

Test outcomes beyond HTTP 200

Choose tests that exercise state changes and downstream dependencies.

For a portal, test authentication and an authorized action with a controlled test account. For a lead form, trace the synthetic submission through to its CRM record. For a queue-backed operation, confirm that the task reaches the worker and completes at the intended destination.

Record an expected result and an observed result. “Tested the form” is difficult to review. “Synthetic submission reference X created one correctly routed CRM record” is a much clearer acceptance statement.

Check relevant logs for new failures through the approved monitoring tools. Keep test data and evidence free of real customer information wherever possible.

If you encounter evidence suggesting compromise, escalate through incident response. Applying a patch does not establish the absence of prior access or remove every possible consequence of a compromise.

Give marketing a usable handoff

The engineering handoff should state which environments were verified, what evidence supports that conclusion, what remains unresolved and which workflows passed.

It should not silently authorize every business action. Campaign owners still need to decide whether the destination and lead-delivery path are ready for traffic.

The Scalematix guide to website security response covers that commercial decision and the communication around it. Keeping the two acceptance decisions explicit helps prevent a technical success from becoming a misunderstood business promise.

Close the record with evidence

A useful closeout is specific enough for another engineer to review later:

“The scoped applications are listed in the inventory. The vendor's notice confirms both fixes in the recorded package. The serving pool now runs the verified artifact. The selected workflows passed. These remaining uncertainties have named owners.”

That standard scales from one managed WordPress site to a fleet of applications. The tooling changes; the claims you need to support remain recognizable.

Which gap is hardest to verify in your environment: the inventory, the running processes, or the downstream workflow?

By Faraz Ahmad. Generated with AI assistance and checked against the linked official advisory. All deployment examples are illustrative; no client incidents or test results are claimed.

Stop Parsing PNG as JSON: A QR Code API Integration in Node.js

Faraz Ahmad — Fri, 25 Sep 2026 07:09:10 +0000

A QR API can return three very different things from the same endpoint: binary PNG, JSON containing SVG markup, or JSON containing a Base64 PNG data URL. If your client always calls response.json(), the first PNG request will fail. That is the integration bug this tutorial prevents.

I work on StadiaSoft’s QR Code Generator API. It makes static codes; it does not provide dynamic redirects, edit destinations later, or collect scan analytics. The examples below use its RapidAPI gateway, but the response-handling pattern applies to other image APIs too.

The transport contract matters

Requested format	HTTP response	How to read it
`png`	`image/png` bytes	`arrayBuffer()`
`svg`	JSON with SVG string in `data`	`json()`
`base64`	JSON with PNG data URL in `data`	`json()`

Use Node.js 18+ and keep your RapidAPI key server-side. RapidAPI requires both the host and key headers.

const host = "qr-code-generator-api63.p.rapidapi.com";
const key = process.env.RAPIDAPI_KEY;
if (!key) throw new Error("Missing RAPIDAPI_KEY");

async function generateQR(text, format = "png") {
  const response = await fetch(`https://${host}/api/v1/qr/generate`, {
    method: "POST",
    headers: {
      "content-type": "application/json",
      "x-rapidapi-host": host,
      "x-rapidapi-key": key,
    },
    body: JSON.stringify({ text, format, size: 500, margin: 4 }),
  });

  if (!response.ok) {
    throw new Error(`QR API ${response.status}: ${await response.text()}`);
  }
  if (format === "png") {
    if (!response.headers.get("content-type")?.includes("image/png")) {
      throw new Error("Expected image/png");
    }
    return Buffer.from(await response.arrayBuffer());
  }
  const data = await response.json();
  if (!data.success || data.format !== format) {
    throw new Error("Unexpected response shape");
  }
  return data.data;
}

The PNG path returns bytes you can hand to a PDF tool or image storage service. The Base64 path returns a string beginning data:image/png;base64,. SVG returns markup in JSON. Do not treat either string as a URL hosted by the provider.

Bulk requests have two meters

For ticket or label jobs, POST /api/v1/qr/generate/bulk takes 1–50 items and returns Base64 results with per-item success or failure. Inspect every item; HTTP 200 does not mean all 50 were generated.

A successful 10-item batch uses one Requests unit and 10 QRCodes units. The current Basic plan has 50 of each unit per month. This means a 50-code batch can exhaust the code allowance even though it is only one HTTP call. Large responses can also hit a 4 MB safety limit, so chunk jobs thoughtfully. Check the current plans before production volume.

Make the code scannable

The API defaults to a four-module margin for a reason: DENSO WAVE specifies a four-module quiet zone. Preserve it in the final layout. Higher error correction is not a substitute for good contrast and adequate printed size; DENSO WAVE explains the capacity tradeoff. Test the actual print, lighting, camera and destination URL, especially when using branded colors. Never encode secrets into a QR payload.

If all you need is one QR inside a Node process, the open-source node-qrcode library may be simpler than a hosted API. Use a hosted service when its shared interface and managed execution fit your workflow.

The full original guide on StadiaSoft covers output choices, quotas, troubleshooting and print checks in more depth. This DEV edition focuses on the binary-versus-JSON trap. I am affiliated with the API provider; the free Basic allowance is currently 50 requests and 50 generated codes per month.

Build an Explainable Vendor-Risk Gate in Node.js

Faraz Ahmad — Tue, 22 Sep 2026 22:27:32 +0000

A vendor signs up with a company domain. Your application wants one fast answer: approve or reject?

The network cannot give you that answer. It can give you evidence.

In this tutorial, we will call a domain-intelligence API, normalize its response and return one of three application decisions:

type Decision = "allow" | "review" | "block";

The implementation uses registration, DNS, TLS, HTTPS and browser-header signals. It deliberately does not call a technically healthy site “safe.”

1. Define the boundary

The API can observe:

RDAP registration age, expiry and status;
public DNS and nameserver configuration;
TLS trust, hostname coverage and expiry;
HTTPS reachability and redirects;
selected HTTP security headers.

It cannot prove:

who controls the domain;
whether the business is legitimate;
whether the site contains malware or phishing content;
how the domain will behave tomorrow.

That boundary belongs in code review, product copy and user-facing explanations.

2. Call the endpoint with a deadline

Store the RapidAPI key in the environment. Copy the exact host from the marketplace snippet.

const API_HOST =
  "domain-intelligence-website-trust-score.p.rapidapi.com";

async function fetchDomainAudit(domain, { forceRefresh = false } = {}) {
  const query = new URLSearchParams({
    domain,
    timeout_ms: "6000",
    force_refresh: String(forceRefresh),
  });

  const response = await fetch("https://" + API_HOST + "/audit?" + query, {
    headers: {
      "x-rapidapi-host": API_HOST,
      "x-rapidapi-key": process.env.RAPIDAPI_KEY,
    },
    signal: AbortSignal.timeout(12_000),
  });

  const body = await response.json();

  if (!response.ok) {
    const error = new Error(
      body?.error?.message ?? "Audit failed with " + response.status,
    );
    error.status = response.status;
    error.requestId = body?.request_id;
    throw error;
  }

  return body;
}

The external timeout is longer than the requested audit timeout so the API can return a structured failure instead of being cut off by the caller first.

3. Normalize only the fields your policy understands

Do not spread the provider response through your whole application. Build an adapter.

function normalizeAudit(raw = {}) {
  const findings = Array.isArray(raw.findings) ? raw.findings : [];

  return {
    domain: raw.domain ?? null,
    score: Number.isFinite(raw.score?.value) ? raw.score.value : null,
    grade: raw.score?.grade ?? null,
    provisional: raw.score?.provisional === true,
    maximumPossible: raw.score?.maximum_possible ?? null,
    topRecommendation: raw.summary?.top_recommendation ?? null,
    severeFindings: findings.filter((finding) =>
      ["critical", "high"].includes(finding.severity),
    ),
    findings: findings.map(({ code, severity, title, recommendation }) => ({
      code,
      severity,
      title,
      recommendation,
    })),
    checks: raw.checks ?? {},
  };
}

Stable finding codes are better policy inputs than human-readable messages, which can change for clarity.

4. Separate evidence from the business decision

function decideVendor(evidence, policy = {}) {
  const allowAt = policy.allowAt ?? 75;
  const blockBelow = policy.blockBelow ?? 40;

  if (evidence.provisional || evidence.score === null) {
    return { decision: "review", reason: "incomplete technical evidence" };
  }

  if (evidence.severeFindings.length > 0) {
    return { decision: "block", reason: evidence.severeFindings[0].code };
  }

  if (evidence.score < blockBelow) {
    return { decision: "block", reason: "score below " + blockBelow };
  }

  if (evidence.score >= allowAt) {
    return {
      decision: "allow",
      reason: "technical posture meets vendor policy",
    };
  }

  return { decision: "review", reason: "mixed technical evidence" };
}

These thresholds are illustrative. A marketplace seller, a payroll vendor and a public-link preview need different policies. Keep the numbers configurable and record the version of the policy used for each decision.

5. Fail into review during outages

A timeout does not make a vendor fraudulent.

export async function assessVendorDomain(domain, policy) {
  const checkedAt = new Date().toISOString();

  try {
    const raw = await fetchDomainAudit(domain);
    const evidence = normalizeAudit(raw);
    const outcome = decideVendor(evidence, policy);

    return { checked: true, checkedAt, ...outcome, evidence };
  } catch (error) {
    return {
      checked: false,
      checkedAt,
      decision: "review",
      reason: "domain evidence temporarily unavailable",
      errorCode: error.status === 429 ? "RATE_LIMITED" : "AUDIT_UNAVAILABLE",
      requestId: error.requestId,
    };
  }
}

For transient failures, retry in a worker with exponential backoff. Do not lock a person out because an RDAP server or certificate endpoint was temporarily slow.

6. Test the policy, not a live score

External evidence changes. Unit tests should use fixtures.

import test from "node:test";
import assert from "node:assert/strict";

test("provisional evidence goes to review", () => {
  const result = decideVendor({
    score: 80,
    provisional: true,
    severeFindings: [],
  });
  assert.equal(result.decision, "review");
});

test("a critical finding blocks even with a high score", () => {
  const result = decideVendor({
    score: 82,
    provisional: false,
    severeFindings: [{ code: "DOMAIN_EXPIRED", severity: "critical" }],
  });
  assert.deepEqual(result, {
    decision: "block",
    reason: "DOMAIN_EXPIRED",
  });
});

test("middle scores require review", () => {
  const result = decideVendor({
    score: 62,
    provisional: false,
    severeFindings: [],
  });
  assert.equal(result.decision, "review");
});

Add integration tests with domains you control, but do not assert that a public domain always returns the same score.

7. Add the evidence your workflow still needs

For real vendor onboarding, combine the technical audit with:

legal-entity and business-registration checks;
proof of domain control;
sanctions or compliance screening where appropriate;
bank-account and payout controls;
malware/phishing intelligence when security risk requires it;
human review and an appeal path.

The domain score helps route work. It should not become a black-box denial system.

Try the workflow

The Domain Intelligence & Website Trust Score API returns the five evidence groups, an explainable score, stable finding codes and remediation. The Basic plan includes 50 requests per month.

For the complete score model, bulk example and implementation boundaries, see the StadiaSoft domain reputation checker guide.

Disclosure: I publish the RapidAPI product referenced here. The tutorial intentionally documents what it cannot prove.

References

Build a Tri-State Email Risk Gate in Node.js

Faraz Ahmad — Sun, 20 Sep 2026 17:44:18 +0000

Most email-validation examples finish with code like this:

if (result.valid) {
  acceptEmail();
}

That is convenient—and usually too lossy.

Syntax, DNS, SMTP and risk checks produce different kinds of evidence. A receiving server may be healthy but refuse to reveal whether a mailbox exists. A catch-all domain may accept any recipient. A role account can be valid but unsuitable for one workflow and perfect for another.

In this tutorial, we will wrap an email validation API in a stable Node.js service that returns three decisions:

allow
review
block

The result is easier to test, safer during outages and more honest about uncertainty.

1. Define an internal contract first

Do not let your application depend directly on every field returned by an external provider. Define the output your product needs.

/**
 * @typedef {Object} EmailAssessment
 * @property {"allow"|"review"|"block"} decision
 * @property {string} reason
 * @property {string} status
 * @property {boolean} checked
 * @property {string} checkedAt
 * @property {object=} evidence
 */

The review state prevents two common bugs:

treating an inconclusive SMTP result as proof that an address is bad;
treating a catch-all domain as proof that a specific mailbox exists.

2. Call the API with a deadline

Node.js provides a global fetch() in current releases. Keep the RapidAPI key in an environment variable and copy the exact host from the marketplace snippet.

const RAPIDAPI_HOST = "email-verify-api1.p.rapidapi.com";

async function requestVerification(email, mode = "power") {
  const response = await fetch(
    `https://${RAPIDAPI_HOST}/api/v1/verify`,
    {
      method: "POST",
      headers: {
        "content-type": "application/json",
        "x-rapidapi-host": RAPIDAPI_HOST,
        "x-rapidapi-key": process.env.RAPIDAPI_KEY,
      },
      body: JSON.stringify({ email, mode }),
      signal: AbortSignal.timeout(mode === "quick" ? 5_000 : 35_000),
    },
  );

  const body = await response.json();

  if (!response.ok) {
    const error = new Error(body.error ?? "Email verification failed");
    error.status = response.status;
    throw error;
  }

  return body.data;
}

RapidAPI expects both authentication headers. The timeout is intentionally longer for a deep check because remote mail servers control part of its latency.

3. Normalize provider evidence

A Power-mode response can expose syntax, MX, SMTP and risk fields. We only select the fields our policy understands.

function normalizeEvidence(raw = {}) {
  return {
    status: String(raw.status ?? "unknown").toLowerCase(),
    score: Number.isFinite(raw.overall_score)
      ? raw.overall_score
      : null,
    safeToSend: raw.is_safe_to_send === true,
    syntaxValid:
      raw.is_valid_syntax === true
        ? true
        : raw.is_valid_syntax === false
          ? false
          : null,
    mxAcceptsMail: raw.mx_accepts_mail === true,
    smtpConnected: raw.can_connect_smtp === true,
    deliverable: raw.is_deliverable === true,
    disposable: raw.is_disposable === true,
    roleAccount: raw.is_role_account === true,
    catchAll: raw.is_catch_all === true,
    inboxFull: raw.has_inbox_full === true,
    disabled: raw.is_disabled === true,
    spamtrap: raw.is_spamtrap === true,
  };
}

Notice that missing Boolean values do not automatically become positive evidence. An absent is_catch_all is different from a confirmed false in some integrations, so tighten this normalization if your application must preserve null explicitly.

4. Apply a policy—not a score threshold

Scores are helpful summaries, but hard-coding score > 70 hides the reason behind a decision. Start with explicit high-risk signals.

function decide(evidence) {
  const blockingStatuses = new Set([
    "invalid",
    "disabled",
    "disposable",
    "spamtrap",
  ]);

  if (
    evidence.syntaxValid === false ||
    evidence.disposable ||
    evidence.disabled ||
    evidence.spamtrap ||
    blockingStatuses.has(evidence.status)
  ) {
    return {
      decision: "block",
      reason: `high-risk result: ${evidence.status}`,
    };
  }

  if (
    evidence.status === "safe" &&
    evidence.safeToSend &&
    !evidence.catchAll
  ) {
    return {
      decision: "allow",
      reason: "positive mailbox and risk signals",
    };
  }

  return {
    decision: "review",
    reason: `inconclusive or contextual result: ${evidence.status}`,
  };
}

Role accounts intentionally fall into context-dependent handling. A SaaS signup may allow them. A consumer rewards program may review them. A support-ticket system should probably expect them.

5. Fail into review during an outage

If the verification service times out, the address does not suddenly become invalid.

export async function assessEmail(email, { mode = "quick" } = {}) {
  const checkedAt = new Date().toISOString();

  try {
    const raw = await requestVerification(email, mode);
    const evidence = normalizeEvidence(raw);

    return {
      checked: true,
      checkedAt,
      status: evidence.status,
      evidence,
      ...decide(evidence),
    };
  } catch (error) {
    return {
      checked: false,
      checkedAt,
      status: "unavailable",
      decision: "review",
      reason: "verification service unavailable",
    };
  }
}

Whether review means “allow signup but require confirmation” or “hold the CRM record” belongs to the calling application.

6. Test policy branches without calling the network

The most valuable tests exercise your decisions, not a provider’s live score.

import test from "node:test";
import assert from "node:assert/strict";

test("safe non-catch-all address is allowed", () => {
  const evidence = normalizeEvidence({
    status: "safe",
    is_safe_to_send: true,
    is_valid_syntax: true,
    is_catch_all: false,
  });

  assert.equal(decide(evidence).decision, "allow");
});

test("unknown address is reviewed, not blocked", () => {
  const evidence = normalizeEvidence({ status: "unknown" });
  assert.equal(decide(evidence).decision, "review");
});

test("disposable address is blocked by this policy", () => {
  const evidence = normalizeEvidence({
    status: "disposable",
    is_disposable: true,
  });

  assert.equal(decide(evidence).decision, "block");
});

Add cases for catch_all, role_account, inbox_full, provider timeouts and malformed input.

Quick versus power mode

Use quick mode for latency-sensitive checks. It can evaluate syntax, disposable status, domain/MX readiness and other fast signals, but it does not prove that an individual inbox exists.

Use power mode when deeper SMTP/mailbox evidence justifies a slower response. Even then, preserve unknown: providers may restrict address probing, defer connections or return insufficient evidence.

For signup, a good pattern is quick verification plus a confirmation email. For CRM cleanup, use deeper verification asynchronously.

Production guardrails

Before shipping, add:

rate limits to prevent address enumeration;
redacted or hashed email logs;
explicit retry rules for 429 and transient 5xx responses;
latency and status-distribution metrics;
short, policy-appropriate cache windows;
suppression-list checks that verification cannot override;
a clear retention policy for personal data.

Remember: reachability is not consent, and verification is not an inbox-placement guarantee.

Try it with controlled addresses

The Email Verification API on RapidAPI exposes quick and power checks plus an asynchronous bulk workflow. The Basic plan includes 50 requests per month.

I also published a longer implementation guide on StadiaSoft covering bulk polling, failure handling and deliverability boundaries.

Test with addresses you control, inspect every field, and change the policy to match your use case before it touches production traffic.

Disclosure: I publish the RapidAPI product referenced in this tutorial. The code and decision model are provider-aware but intentionally preserve the limitations of SMTP verification.

References

Build a Lightweight BuiltWith Alternative with Node.js

Faraz Ahmad — Fri, 18 Sep 2026 06:37:02 +0000

If you already have a list of account domains, you can build useful technographic enrichment without recreating a global website database. The job is smaller: fetch each public site, detect supported fingerprints, preserve the evidence, and write only high-confidence fields into the CRM.

This tutorial builds that workflow in Node.js with the CMS Checker & Website Technology Detector API. It also covers the limitation that matters most: a real-time website lookup is not the same product as a historical technographic database.

Fast path: the Basic plan includes 50 requests per month. Use those requests on known sites before allowing any detection to change a CRM workflow.

When a lightweight BuiltWith alternative is the right fit

A real-time lookup API is a strong fit when you already possess the domains and need fresh public signals for routing, integration discovery, migration prospecting, or account research. A full technographic database is the better tool when the task starts with “find every company using technology X,” or when historical adoption dates matter. A browser extension is better for one-off human research.

That distinction prevents bad expectations. “Alternative” describes an overlapping job, not identical coverage.

What an evidence-backed detector should return

Public sites expose clues in HTML paths, generator tags, script URLs, response headers, cookies, CDNs, and redirects. One signal can mislead, so a useful detector returns more than a technology name.

For every match, preserve:

technology name and category
confidence from 0 to 99
version when a public signal exposes one
official website
one or more evidence objects with the source, matched value, explanation, and per-signal confidence

The current StadiaSoft catalog covers 40 technologies across 19 categories, including CMS platforms, ecommerce, JavaScript frameworks, analytics, hosting, CDNs, marketing automation, and payments.

Make the first request from Node.js

Node.js 21 and later include a stable browser-compatible fetch(). Keep the RapidAPI key on the server.

RAPIDAPI_HOST=copy-the-host-from-your-rapidapi-snippet
RAPIDAPI_KEY=your-rapidapi-application-key

Use GET /detect for the fastest lookup:

const params = new URLSearchParams({
  url: "shopify.com",
  timeout_ms: "8000",
});

const endpoint =
  "https://" +
  process.env.RAPIDAPI_HOST +
  "/api/v1/technology-stack/detect?" +
  params;

const response = await fetch(endpoint, {
  headers: {
    "x-rapidapi-key": process.env.RAPIDAPI_KEY,
    "x-rapidapi-host": process.env.RAPIDAPI_HOST,
  },
});

if (!response.ok) {
  const errorBody = await response.text();
  throw new Error(
    "Technology lookup failed (" + response.status + "): " + errorBody,
  );
}

const result = await response.json();

console.log({
  finalUrl: result.final_url,
  detected: result.summary.technologies_detected,
  categories: result.summary.categories,
  technologies: result.technologies,
});

RapidAPI authentication requires both X-RapidAPI-Key and X-RapidAPI-Host. Never commit the key, put it in a public URL, or paste it into a support request.

Use Evidence → Confidence → Action

A safe enrichment rule has three layers.

1. Evidence

Preserve the public signal that produced the match: a vendor-specific header, generator tag, two independent asset paths, or a platform cookie.

2. Confidence

Choose an automation threshold. A score of 90 or above may be sufficient for routing, while a lower score may require manual review. The correct threshold depends on the cost of a false positive.

3. Action

Connect a confirmed category to one explicit workflow:

Shopify or WooCommerce can route an account to an ecommerce segment.
WordPress can trigger a migration checklist.
HubSpot can add an integration-fit tag.
Stripe or PayPal can enrich a payments field.
Vercel or Netlify can route a site to a modern-hosting sequence.

A public signal does not prove contract value, deployment size, or company-wide use. It proves that the checked page exposed that signal at that time.

Normalize the result for a CRM

Keep the full evidence in a JSON-capable field, then derive a small number of top-level properties for filters.

function normalizeTechnologyResult(result) {
  const observedAt = new Date().toISOString();

  const technologies = result.technologies.map((technology) => ({
    name: technology.name,
    category: technology.category,
    confidence: technology.confidence,
    version: technology.version ?? null,
    evidence_sources: [
      ...new Set(technology.evidence.map((item) => item.source)),
    ],
    observed_at: observedAt,
  }));

  const highConfidence = technologies.filter(
    (technology) => technology.confidence >= 90,
  );

  return {
    tech_lookup_status: "complete",
    tech_checked_at: observedAt,
    tech_final_url: result.final_url,
    tech_categories: [...new Set(highConfidence.map((item) => item.category))],
    tech_names: highConfidence.map((item) => item.name),
    tech_evidence: technologies,
    tech_request_id: result.request_id,
  };
}

This structure remains stable when the detection catalog grows. It also leaves an audit trail for anyone reviewing a routing decision later.

Process a small batch safely

The bulk endpoint accepts one to five domains, and each result succeeds or fails independently. For larger imports, split domains into groups of five, limit concurrency in your worker, and retry only transient fetch failures.

A practical refresh policy is a lookup during account creation followed by weekly or monthly checks for active accounts. Most website stacks do not need minute-by-minute polling.

Accuracy limitations you should document

Technology detection is fingerprinting, not privileged inspection. A tool can be missed when:

production builds remove recognizable markers
a reverse proxy strips headers
scripts load only after user interaction
the homepage does not use a tool present on an inner page
a consent manager blocks analytics
assets are proxied through the site’s own domain
the technology is entirely backend or internal

False positives are possible too. Editorial text, a third-party widget, or a stale script can resemble a platform marker. Require specific evidence and a high confidence score before triggering outreach or a customer-facing recommendation.

SSRF protection is part of the product

A detector fetches caller-supplied URLs, so server-side request forgery is a core risk. This API accepts only HTTP and HTTPS on ports 80 and 443. It rejects IP literals, local hostnames, private networks, and reserved ranges. Every redirect destination is normalized, resolved, and checked again before connection. Fetches stop after five redirects and responses are capped at 2 MB.

If you build your own detector, one hostname regex is not enough. DNS can change between validation and connection, alternate IP forms can bypass naive rules, and a public URL can redirect to an internal service.

A useful 50-request evaluation

Use the free monthly allowance deliberately:

Test ten known CMS sites.
Test ten framework and hosting sites.
Test ten martech-heavy sites.
Test ten low-signal custom sites.
Spend ten requests on repeats, redirects, invalid input, and caching behavior.

Record expected categories before running the test. Review mismatches manually and inspect the evidence instead of judging the detector from one impressive demo.

Run the five-domain test

Open the CMS Checker & Website Technology Detector API on RapidAPI and use the 50 free monthly requests to validate the workflow against domains whose stacks you can independently verify.

The complete comparison table, FAQ, sources, and implementation notes are available in the original StadiaSoft guide.

Sources

Build an SPF, DKIM & DMARC Checker API with Node.js

Faraz Ahmad — Wed, 16 Sep 2026 23:35:02 +0000

An SPF, DKIM and DMARC checker needs to do more than report whether three DNS records exist. A domain can publish SPF yet have no DMARC policy, sign mail with DKIM but use an unexpected selector, or have strong authentication records while missing transport-security controls.

That makes a useful mail-security audit more than a set of three DNS lookups. It needs to collect evidence, distinguish a confirmed failure from an unknown result, and return fixes in a sensible order.

This guide shows how to build an API-based email security workflow that audits MX, SPF, DKIM, DMARC, MTA-STS, TLS-RPT and BIMI from Node.js. It also explains what the result can—and cannot—tell you about deliverability.

What each mail-security check tells you

Check	What it answers	Audit weight
MX	Can other mail systems find this domain's mail exchangers?	20
SPF	Which servers are authorized to send for the domain?	20
DMARC	What should receivers do when alignment fails, and where should reports go?	25
DKIM	Can a receiver verify a message's cryptographic signature?	15
MTA-STS	Does the domain publish an HTTPS policy requiring secure SMTP transport?	10
TLS-RPT	Where should TLS delivery failures be reported?	5
BIMI	Does the domain publish a brand-indicator record?	5

The first four controls are the core of an email-authentication review. The remaining controls improve transport visibility, policy enforcement and brand signaling.

One important distinction: SPF validates an envelope sender, DKIM validates a signed message, and DMARC evaluates alignment between an authenticated identity and the address visible to the recipient. A record merely existing does not guarantee that all legitimate mail passes.

Audit a domain from Node.js

The Domain Mail Security & Deliverability Audit API supports a fast GET request and a JSON POST request. In RapidAPI, copy your exact host value from the marketplace code snippet rather than hard-coding the placeholder below.

const domain = "example.com";
const selectors = ["google", "selector1"];

const params = new URLSearchParams({
  domain,
  dkim_selectors: selectors.join(","),
});

const response = await fetch(
  `https://${process.env.RAPIDAPI_HOST}/api/v1/mail-security/audit?${params}`,
  {
    headers: {
      "x-rapidapi-key": process.env.RAPIDAPI_KEY,
      "x-rapidapi-host": process.env.RAPIDAPI_HOST,
    },
  },
);

if (!response.ok) {
  const body = await response.text();
  throw new Error(`Mail-security audit failed (${response.status}): ${body}`);
}

const audit = await response.json();
console.log({
  domain: audit.domain,
  score: audit.score,
  summary: audit.summary,
  findings: audit.findings,
});

Keep the RapidAPI key in an environment variable or secret manager. Do not commit it to your repository or expose it in browser-side JavaScript.

The API returns the domain, audit timing, score and grade, individual checks, a summary, and prioritized findings. That structure makes the result suitable for dashboards, onboarding rules, scheduled monitoring and remediation tickets.

Why DKIM needs special handling

You can look up SPF at the root domain and DMARC at _dmarc.example.com. DKIM is different. Its DNS name includes a selector:

selector._domainkey.example.com

The selector is chosen by the sending provider or mail administrator. DNS does not publish a universal index of every selector a domain uses, so an auditor cannot reliably discover all of them.

If you know the provider, pass likely selectors with the request. For example, Google Workspace often uses google, while other providers or self-managed systems may use values such as selector1, selector2, or a date-based selector.

When no tested selector resolves, the responsible result is unknown, not fail. The score should also be treated as provisional. A definitive DKIM failure requires evidence from an actual signed message or the selector configured by the sender.

Turn findings into a repair plan

A raw DNS dump is not a remediation plan. Triage the findings in this order:

Restore mail routing first. Missing or broken MX records can prevent normal delivery.
Fix SPF syntax and authorization. Keep one SPF record, remove obsolete senders, and stay within SPF's DNS-lookup constraints.
Publish DMARC and improve it gradually. Start with reporting if necessary, study legitimate sources, then move toward quarantine or reject when alignment is stable.
Verify DKIM with the correct selectors. Confirm every active sending platform, not just the primary provider.
Add MTA-STS and TLS-RPT together. The policy can require secure transport; reporting provides visibility into failures.
Treat BIMI as an optional final layer. It depends on strong email authentication and may involve additional brand or certificate requirements.

This ordering reduces the chance of tightening policy before legitimate senders are accounted for.

Use the score as a signal, not a verdict

A mail-security score is useful for comparing domains, tracking configuration work and routing high-risk results for review. It is not proof that messages will reach the inbox.

Inbox placement also depends on factors that a DNS and HTTPS posture audit cannot observe, including sender reputation, complaint rates, bounce history, content, sending cadence, recipient engagement and per-message alignment.

The audit described here checks public DNS records and the standard MTA-STS HTTPS policy endpoint. It does not connect to mail exchangers, send test messages, inspect private provider settings or recursively expand every possible SPF include. For deliverability decisions, combine configuration evidence with message headers, provider telemetry and controlled sending tests.

Practical ways to use the result

Agency audits: generate a repeatable technical baseline before recommending email changes.
SaaS onboarding: warn customers about missing authentication before they connect a sending domain.
Vendor screening: identify domains with weak or incomplete mail-security posture.
Scheduled monitoring: detect when records disappear or policies regress.
Support triage: attach structured evidence and prioritized fixes to a ticket.

For monitoring, save both the normalized finding codes and the underlying evidence. Alert on meaningful state changes, not small score movements alone.

SPF, DKIM and DMARC checker FAQ

What does an SPF, DKIM and DMARC checker test?

It looks up the public DNS records used for sender authorization, message signing and authentication policy. A deeper audit can also check MX routing, MTA-STS, TLS-RPT and BIMI, then return the evidence and recommended fixes.

Can a checker find every DKIM record automatically?

No. A DKIM lookup requires the selector used by the sending system, and DNS does not publish a complete list of selectors. Test known provider selectors or inspect the DKIM-Signature header of a real message.

Does passing SPF, DKIM and DMARC guarantee email deliverability?

No. These controls support authentication, but inbox placement also depends on sender reputation, complaints, bounces, content, volume patterns, engagement and per-message alignment.

Can I automate checks with an API?

Yes. A server-side checker API can run during customer onboarding, domain verification, vendor screening or scheduled monitoring. Store both the normalized status and the underlying evidence so changes can be reviewed.

Start with a free audit

The Domain Mail Security & Deliverability Audit API checks seven controls in one request. The Basic plan includes 50 requests per month, so you can test the complete response before choosing a paid plan.

Run a domain in the RapidAPI playground, inspect the evidence behind each check, and use the findings—not just the score—to decide what to fix first.

Originally published on StadiaSoft.