Ironfang Security docs

How it works

Everything happens in the portal under Security, in this order:

1. Add a domain. Paste a domain or URL. IP addresses, public suffixes and reserved names are refused.
2. Verify it. Add the TXT record the portal shows. It is checked automatically, or on demand.
3. Confirm authorisation. Review the scan policy and confirm you are authorised to test the domain.
4. Run a scan. The verification record is checked again, then every category runs.
5. Review findings. Findings are ranked by severity and confidence, each with evidence and a fix.
6. Recheck. The checks behind a finding run again. If the issue is gone, the finding is marked fixed.

Start in the portal. The sections below cover each step in detail.

Verifying a domain

Verification uses a DNS TXT record at _ironfang-verification.<domain> containing ironfang-verification=<token>, with the token from the portal. Only someone who controls the domain's DNS can publish it.

The record, for example.com

Type

TXT

Name

_ironfang-verification.example.com

Value

ironfang-verification=k3v9q2mz7x4t8w1r

Most providers add the domain for you

At most DNS providers the host or name field appends your domain automatically, so enter only _ironfang-verification. Entering the full name creates _ironfang-verification.example.com.example.com, which is never found. The portal shows both the full name and the host label for this reason.

At your DNS provider

Checking the record yourself

Query a public resolver with dig +short TXT _ironfang-verification.example.com @1.1.1.1 or, on Windows, nslookup -type=TXT _ironfang-verification.example.com 1.1.1.1. The answer should contain the value exactly, with nothing before or after it.

$ dig +short TXT _ironfang-verification.example.com @1.1.1.1
"ironfang-verification=k3v9q2mz7x4t8w1r"

Statuses

A token is valid for 7 days and can be replaced at any time before the domain is verified. You can request an immediate check once every 10 seconds per domain. Keep the record in place: it is checked again before every scan.

Troubleshooting

• Check the name first. A doubled domain from the host field is the most common cause.
• Wait a few minutes after adding the record. If a lookup ran before the record existed, resolvers may cache the empty answer for a while.
• Copy the value exactly. Quotes added by your provider are fine; extra spaces or a missing part of the token are not.
• Several TXT values at the same name are fine. A CNAME at that name is not: TXT and CNAME cannot share a name.

Authorisation and scan policy

Verification proves control, not consent. Before the first scan of a domain, someone in your organisation confirms: I confirm I am authorised to assess this domain.

The confirmation is recorded with the person, the time and the scan policy version (currently external-check-v1), and cannot be edited. When the policy changes, scans pause until someone confirms the new version.

Included

• DNS: address and nameserver records, CAA, DNSSEC and dangling records.
• TLS and HTTPS: the certificate, supported TLS versions and cipher strength.
• HTTP security: redirects, security headers, cookies and security.txt, from a handful of ordinary requests.
• Email authentication: SPF, DMARC, DKIM and MX records. No email is sent.
• Exposed services: one connection attempt per port on a fixed list of common services. Nothing is sent to them.
• Technology: the web server, CDN and frameworks your responses disclose.
• Outdated software: versions that look unsupported, reported as potential issues.
• Certificate transparency: hostnames from public logs, listed for review and never scanned.

Never attempted

Exploitation, password and credential attacks, authentication attacks, SQL injection, cross-site scripting, fuzzing, denial-of-service and destructive testing, social engineering and attempts to gain access.

Every scan and result includes this statement: This is an automated external security check. It is not a penetration test, a certification or a formal assessment.

Running a check

A full scan runs every category: DNS, email, TLS, HTTP, technology, exposed services and certificate transparency. Most finish within a few minutes, and the portal shows progress by category.

Scan statuses

A finished scan lists findings, passed checks, observations such as detected technologies, checks that could not complete, known limitations and recommended next actions. Scan history records what was new, fixed or reopened each time.

Hostnames found in certificate transparency logs appear as discoveries on the domain. They are listed for review and never scanned automatically.

Severity and confidence

Every finding has a severity and a separate confidence. Severity is the potential impact; confidence is how strongly the evidence supports the finding. There is no combined score.

Severity

Confidence

Kind

Finding statuses

You can set open, acknowledged, accepted risk or false positive, with a note. Every change is kept in the finding's history.

Each finding keeps the evidence behind it: a DNS answer, certificate, TLS handshake, HTTP response, TCP connection, service greeting or certificate transparency entry.

Every finding links to its page in the check reference: what the check looks at, why it matters and how to fix it.

Rechecking a fix

After a fix, recheck the finding instead of running a full scan. The checks behind it run again on its host:

• If the issue is gone, the finding is marked fixed.
• If it is still there, the finding stays open.
• Either way, the new evidence and result are added to its history.

A finding can be rechecked once every 60 seconds. Full scans also mark findings fixed, or reopen them if the issue returns.

Limits

Free during the preview, with the same limits for every organisation. Requests over a limit return an error code and, for cooldowns, when to retry.

• 5 domains per organisation, of which at most 5 may be waiting for verification.
• One full scan of a domain every 60 minutes.
• 20 scans a day per organisation.
• 1 scan running at a time per organisation.
• One recheck of a finding every 60 seconds.

Each scan makes at most 8 HTTP requests per host and 2 concurrent connections per address, with 150 milliseconds between connection attempts.

The scanner page lists its source addresses and User-Agent for allowlisting.

Authentication

The Security API is the API the portal uses. During the preview it accepts a Warden user token as a bearer token, with the organisation named in X-Ironfang-Tenant.

Authorization: Bearer <Warden user token>
X-Ironfang-Tenant: <organisation id>

Each request also needs a permission in that organisation, checked on every call:

• security.readReading: the overview, domains, scans, findings, activity and the scan policy.
• security.writeChanging anything: adding and removing domains, verification checks, authorisation, starting and cancelling scans, finding statuses and rechecks.

Platform API keys and delegated MCP tokens are refused with 403 api_keys_not_supported during the preview. A missing permission is 403; a failed permission lookup is 503.

API

Base URL https://api.ironfang.com/security. The contract is OpenAPI 3.1 at https://api.ironfang.com/security/openapi.yaml, also as JSON at the same path with .json. Every object belongs to one organisation: anything in another is reported as not found.

Errors

Every error is the same JSON shape. Branch on the code and the HTTP status, never on the message. Cooldowns and rate limits add retry_after_seconds and a Retry-After header.

{
  "error": {
    "code": "scan_cooldown",
    "message": "This domain was scanned recently.",
    "docs": "https://ironfang.com/security/docs#errors",
    "retry_after_seconds": 1740
  },
  "request_id": "01a0c375-7bae-7f02-a3d4-91e6b8c25f70"
}

What it is not

Machine interfaces