Security glossary

These terms appear in the field notes and in the report we email after a scan. Bookmark specific entries via the anchor (/glossary/#dmarc) and link to it freely.

Each definition is intentionally short; the field notes go deeper into the how and the why.

Email authentication

Three DNS records and a couple of helpers decide whether mail claiming to come from your domain is delivered, quarantined, or bounced. Get these right and spoofed mail stops in its tracks; get them wrong and your real mail goes to spam.

SPF (Sender Policy Framework)

A DNS TXT record that lists which hosts are allowed to send mail using your domain in the SMTP envelope (the MAIL FROM address, also called the return-path). A receiving server looks up the record, compares it with the connecting IP address, and records a pass, fail, softfail, neutral, or temporary error.

A typical record looks like: v=spf1 include:_spf.google.com include:mailgun.org -all. The -all at the end says “anything not listed should fail SPF”; whether the receiver rejects the message depends on its own policy and on DMARC. ~all (soft fail) and ?all (neutral) are weaker and are usually temporary rollout settings, not a final state.

SPF alone does not prove the address a human reads in the “From” field. That is DMARC’s job — see DMARC alignment.

See also: DKIM, DMARC, DMARC alignment.

DKIM (DomainKeys Identified Mail)

A cryptographic signature attached to outgoing mail. The sender signs selected headers and the message body with a private key; the receiver looks up the matching public key in DNS at <selector>._domainkey.<domain> and verifies the signature.

A valid DKIM signature proves two things: the signed parts of the message still match the hash, and the signing key belongs to whoever controls that DNS record. It does not prove the “From” address shown to the reader, because the signing domain can be different from the visible sender. For that you need DMARC alignment.

Selectors let one domain rotate keys without downtime: deploy a new key under a new selector, switch sending to it, then retire the old DNS record after a grace window.

See also: DMARC, DMARC alignment.

DMARC (Domain-based Message Authentication, Reporting and Conformance)

A DNS policy record at _dmarc.<domain> that tells participating receivers what to do when mail claiming to be from the domain fails DMARC, and where to send aggregate reports.

The policy moves from monitor mode to enforcement in three stages:

p=none — observe only; receivers still deliver and send you reports so you can learn who is sending as you.
p=quarantine — receivers move failing mail to spam.
p=reject — receivers reject failing mail, usually during the SMTP transaction.

Most domains start at none to collect data, fix legitimate senders that are failing, and then move to quarantine and finally reject. Staying at none indefinitely is the most common misconfiguration — it gives spoofers a free pass.

DMARC also requires alignment: see the next entry.

See also: SPF, DKIM, DMARC alignment, BIMI.

DMARC alignment

The rule that links SPF or DKIM back to the address a human actually sees. SPF authorises the envelope MAIL FROM. DKIM signs on behalf of a domain. Alignment requires that at least one of those domains matches the visible From: header.

Without alignment a spammer could pass SPF for [email protected] while showing From: [email protected] — DMARC closes that hole. Strict alignment requires an exact domain match. Relaxed alignment, the default, accepts the same organizational domain: mail.example.com can align with example.com, but example.net cannot.

See also: DMARC, SPF, DKIM.

MTA-STS (Mail Transfer Agent Strict Transport Security)

A policy file published over HTTPS at mta-sts.<domain>/.well-known/mta-sts.txt plus a TXT record at _mta-sts.<domain>. Together, as defined in RFC 8461, they tell sending servers: “use TLS when delivering to me; here are the MX hostnames whose certificates I accept; if the connection cannot be secured, fail delivery instead of falling back to clear text.”

MTA-STS plugs a long-standing weakness in SMTP: STARTTLS is best-effort, and an attacker between mail servers can strip the TLS upgrade and read the message. MTA-STS turns that downgrade into a deliverability failure instead of a silent compromise.

See also: TLS-RPT.

TLS-RPT (SMTP TLS Reporting)

A companion to MTA-STS, defined in RFC 8460, that asks sending mail servers to report TLS delivery problems. You publish a TXT record at _smtp._tls.<domain> with a rua=mailto: address; supporting senders send daily JSON reports that summarise certificate errors, policy failures, and downgrade attempts. Treat it as the monitoring layer beneath the MTA-STS policy.

See also: MTA-STS.

BIMI (Brand Indicators for Message Identification)

A way for senders that already enforce DMARC at quarantine or reject to publish a logo, and have supporting mail clients show it next to authenticated messages. Some mailbox providers also require a Verified Mark Certificate (VMC). BIMI is a trust signal, not an authentication step — but it gives operators a concrete reason to finish the DMARC rollout that many domains stall on.

See also: DMARC.

DNS

DNS is the public phone book of the internet. Most external security signals live in it — which means anyone can read them, including attackers building a target list.

DNS (Domain Name System)

The system that maps human-friendly names like zmam.ai to machine-friendly addresses and other public facts about a domain. DNS records are public by design: anyone can ask an authoritative server for A, MX, TXT, or CAA data. That makes DNS both operational plumbing and the first map an attacker reads before probing a target.

See also: DNSSEC.

A / AAAA record

The records that resolve a name to an IPv4 (A) or IPv6 (AAAA) address. Most other security questions about a hostname start here: does api.example.com point to your cloud account, a CDN, an old hosting provider, or an address nobody on the team recognises?

CNAME record

An alias that says “for this name, look up that other name instead.” Common for fronting services with a CDN or pointing www at a hosting platform. CNAMEs are also a frequent source of subdomain-takeover risk: when the target service is deleted but the CNAME remains, the record becomes a dangling pointer an attacker may be able to claim.

See also: Dangling DNS, Subdomain takeover.

MX record

The records that tell the world which servers receive mail for a domain. Each MX entry has a priority (lower numbers are tried first) and a hostname. Missing or wrong MX records bounce legitimate mail; stale MX records can leave old mail services receiving messages for a domain you think has moved.

TXT record

A free-form text record. Most modern security signals — SPF, DKIM public keys, DMARC, MTA-STS, domain ownership proofs — ride in TXT records. The record name or value tells you what it means: v=spf1 for SPF, _dmarc.<domain> for DMARC, <selector>._domainkey.<domain> for DKIM.

NS record (Name Server)

Identifies which servers are authoritative for a zone. If those servers are lame (delegated but not actually answering), the domain may fail to resolve. If a delegation points at a deprovisioned third-party nameserver that can be re-created, the result can be full-zone takeover. NS records change rarely; a sudden change is worth investigating.

CAA record (Certification Authority Authorization)

A DNS record naming the certificate authorities you allow to issue certificates for your domain. A typical entry: 0 issue "letsencrypt.org". Browsers do not consult CAA at handshake time; the policy applies at issuance time. A CA is required to check CAA before issuing, so a CA not listed should refuse the request even if the requester can prove control of the name.

Add 0 iodef "mailto:security@yourdomain" to receive incident reports when a refused issuance happens.

See also: TLS.

DNSSEC (DNS Security Extensions)

A set of DNS extensions that cryptographically sign records, so a resolver can detect tampering between the authoritative server and itself. DNSSEC does not encrypt DNS; it gives integrity and origin authentication for answers. It is operationally fussy, but valuable where the cost of a poisoned record is high: banks, registrars, and large mail providers.

FQDN (Fully Qualified Domain Name)

A complete hostname, including every label up to the root — for example api.zmam.ai. with the trailing dot. Most tools accept the dot-less form, but in DNS syntax the trailing dot marks “start from the root, not relative to a search suffix.”

Wildcard certificate

A TLS certificate issued for *.example.com. It covers any single label directly under example.com, such as api.example.com, but not a.b.example.com. That convenience has a cost: a leaked private key compromises every covered subdomain at once. Pair wildcard certificates with CAA records and short rotation cycles.

See also: CAA record.

Dangling DNS

A DNS record that still points at a resource you no longer own — most often a CNAME to a former cloud bucket, a retired SaaS host, or a deleted Heroku app. If the target name is claimable by anyone, an attacker can register it and serve content under your subdomain. zmam.ai checks for these automatically.

See also: Subdomain takeover, CNAME record.

Transport security (TLS)

The lock icon in the address bar is just the visible result of a TLS handshake. The real story is which protocol version and cipher both ends agreed on, and whether the certificate chains to a trusted root.

TLS (Transport Layer Security): The cryptographic protocol that wraps an HTTP (or SMTP, IMAP, etc.) connection in encryption and server identity. “SSL certificate” is the old name people still use; the protocol moved from SSL to TLS in 1999. The versions to run in production are TLS 1.2 and TLS 1.3, with TLS 1.3 preferred where clients support it.
See also: HSTS.
TLS 1.0 / TLS 1.1 (legacy): Both versions were deprecated by the IETF in 2021 (RFC 8996) and are not acceptable for modern compliance baselines such as PCI DSS. They still appear in the wild because old clients or middleboxes ask for them. Continuing to accept TLS 1.0 or 1.1 is an audit finding regardless of who is asking; disable them and make the remaining clients upgrade.
See also: TLS, TLS 1.3.
TLS 1.2: The workhorse version since 2008. Safe if your cipher suites require forward secrecy and AEAD modes such as GCM or CHACHA20-POLY1305. The dangerous parts of TLS 1.2 are legacy choices — RC4, 3DES, CBC-with-SHA1, static RSA key exchange, and anything with EXPORT in the name. A healthy site should not negotiate any of them.
See also: Cipher suite.
TLS 1.3: The 2018 redesign (RFC 8446). It removes weak cipher modes, makes forward secrecy mandatory, cuts the normal handshake to one round trip, and encrypts more handshake metadata. Enable it everywhere it is available and prefer it over TLS 1.2 by configuration.
See also: TLS, TLS 1.2.
Cipher suite: A named set of algorithms the two ends agree to use for a TLS connection. In TLS 1.2 the suite covers key exchange, authentication, encryption, and message authentication; in TLS 1.3 it mostly names the AEAD cipher and hash, such as TLS_AES_256_GCM_SHA384. Prefer suites with GCM or CHACHA20-POLY1305; avoid CBC, RC4, 3DES, static RSA, and _SHA1.
See also: TLS 1.2, TLS 1.3.
OCSP stapling (Online Certificate Status Protocol stapling): The server fetches a short-lived signed statement from its CA saying “this certificate is still valid”, and staples it to the TLS handshake. Without stapling, the browser asks the CA itself — slower, and a privacy leak. With stapling enabled, clients can check revocation status without that extra round-trip, although many browsers still soft-fail if the status is missing.

HTTP security headers

A handful of response headers turn a browser from “trusts the server about everything” into “follow the server’s stated rules”. Most are one-line config changes that prevent entire classes of attack.

HSTS (HTTP Strict Transport Security)

A response header telling browsers “for the next N seconds, only connect to me over HTTPS, even if the user typed http:// or clicked a plain link.” A typical value: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload.

HSTS protects every visit after the first successful HTTPS connection by rewriting future HTTP attempts to HTTPS before the request leaves the browser. The very first visit is still strip-vulnerable; HSTS preload closes that bootstrap gap.

See also: HSTS preload, TLS.

HSTS preload

A list browsers ship hard-coded that enforces HTTPS for listed domains from the very first visit — closing the bootstrap gap in HSTS. To get in, your site must serve the right header for at least a year, with includeSubDomains and preload, then submit at hstspreload.org. Removal can take browser release cycles, so make sure every subdomain can live on HTTPS before you apply.

See also: HSTS.

CSP (Content Security Policy)

A response header that lists which sources of script, style, image, frame, and other content the browser is permitted to load on this page. The strongest defence against cross-site scripting (XSS): even if an attacker injects markup, a restrictive CSP refuses to execute it.

Start with Content-Security-Policy-Report-Only plus a report-uri or report-to endpoint to learn what your real pages load, then move to enforcement. Avoid 'unsafe-inline' for scripts; use per-request nonces and, where appropriate, strict-dynamic.

See also: SRI, XSS.

X-Frame-Options

The old way to forbid your pages being loaded inside <iframe> elements on other sites — the foundation of clickjacking defence. DENY blocks all framing; SAMEORIGIN allows framing by the same site. The modern replacement is the frame-ancestors directive in CSP. Send both if you still support older browsers.

See also: Clickjacking.

X-Content-Type-Options

A one-value header — nosniff — that tells the browser to stop second-guessing your declared Content-Type for scripts and styles. Without it, a file uploaded as an image but served from your domain can be interpreted as JavaScript or CSS in a victim’s tab.

Referrer-Policy

Controls how much of the requesting URL leaks in the Referer header on outbound requests. Set it to strict-origin-when-cross-origin (or stricter) so a password-reset URL or a token in a query string does not show up in a third party’s logs. The header name is misspelled as Referer for historical reasons; the policy name is spelled correctly.

Permissions-Policy

Declares which browser features pages from your site (and embedded frames) may use — camera, microphone, geolocation, USB, payment, fullscreen, and dozens more. A tight policy is explicit: deny powerful features by default and enable only the ones a page actually needs.

SRI (Subresource Integrity)

A <script integrity="sha384-…"> attribute on tags loading third-party JavaScript or CSS. The browser hashes the fetched file and refuses to use it if the digest does not match. Defends against compromised CDNs or vendor-side code injection: if the attacker swaps the file, the hash check fails.

Cookie security flags (Secure / HttpOnly / SameSite)

Three attributes you can attach to any cookie:

Secure — the cookie is only sent over HTTPS.
HttpOnly — JavaScript cannot read it via document.cookie, which blunts XSS-driven session theft.
SameSite — controls cross-site sending: Strict (not sent on cross-site navigation), Lax (sent on safe top-level navigations such as GET), or None (sent in all contexts and must be paired with Secure).

Modern session and CSRF defence uses all three, plus CSRF tokens for state-changing requests.

See also: CSRF.

Web application vulnerabilities

The recurring bug shapes that turn an honest server into an attacker’s lever. Patterns here are the OWASP Top 10 you have heard of plus the API-flavoured cousins.

XSS (Cross-Site Scripting): Any class of bug that lets an attacker run JavaScript on your site under another user’s session. Three flavours: stored (saved in a database and served to anyone who views the page), reflected (echoed back from a URL parameter), and DOM-based (introduced by client-side code). Mitigations layer: context-aware output encoding, HTML sanitisation where users are allowed to supply markup, safe DOM APIs, and CSP as the final net.
See also: CSP, SRI.
SQL injection (SQLi): A bug where untrusted input is concatenated into a database query, letting the attacker change the query’s meaning — reading data they should not see, modifying records, or sometimes executing OS commands via database extensions. The proven fix is parameterised queries or prepared statements: the SQL text and the values travel separately, so "' OR 1=1 stays data instead of becoming syntax.
CSRF (Cross-Site Request Forgery): An attacker tricks an authenticated user’s browser into sending a state-changing request — transferring money, changing email — without the user realising. Modern defence combines SameSite cookies with a CSRF token tied to the user’s session and validated on every unsafe method. Checking the Origin or Referer header is still a useful second layer.
See also: Cookie security flags (Secure / HttpOnly / SameSite).
IDOR (Insecure Direct Object Reference): A bug where the server trusts an identifier the client passes (/order/12345) without checking whether the caller is allowed to see that object. Patching one endpoint is rarely enough — IDOR usually points at a missing authorisation layer that must run wherever objects are read or changed. The API version has its own name, BOLA.
See also: BOLA.
BOLA (Broken Object Level Authorization): The number-one item on the OWASP API Security Top 10 — the API equivalent of IDOR. An authenticated user calls GET /v1/accounts/<id> with a neighbour’s id and the server returns the neighbour’s account. Often invisible from the outside; the fix is server-side object-level checks on every request, not hiding IDs or relying on the client.
See also: IDOR.
SSRF (Server-Side Request Forgery): A bug where the server can be tricked into making an HTTP request the attacker chose — and that request runs from inside your network. In cloud environments SSRF is often the path to the metadata service (169.254.169.254) and the temporary credentials it returns. Defence in depth: allowlist outbound destinations, block private, loopback, link-local, and cloud metadata addresses, and require IMDSv2 on EC2 so a simple GET-only SSRF gadget cannot fetch credentials.
RCE (Remote Code Execution): The attacker runs arbitrary code on your server — the worst practical outcome of most other bugs. Common paths: command injection in a shell-out, deserialisation flaws, file-upload handlers that execute their inputs, vulnerable image-processing libraries. RCE in a CVE description means the asset must be patched immediately.
Open redirect: A URL on your site that 302-redirects to a destination the caller controls (/login?next=https://evil.example). On its own a low-severity bug, but it makes phishing more convincing and is often a stepping stone in OAuth or SAML attacks. Fix: allow only relative paths or a small allowlist of trusted redirect destinations.
Path traversal: A bug where a user-supplied filename includes .. or other directory tricks to escape the intended folder and read or write files elsewhere on the server. Standard mitigation: decode and normalise the path, resolve it to an absolute location, and confirm it still sits under the intended root before opening the file. For downloads, an ID-to-file mapping is safer than accepting paths from users.
Clickjacking: Loading your page inside an iframe on an attacker-controlled site, then layering a transparent overlay so a user click hits your page instead of what they see. Modern defence: Content-Security-Policy: frame-ancestors 'self' plus the legacy X-Frame-Options: DENY for older browsers.
See also: X-Frame-Options, CSP.

CVE & vulnerability lifecycle

A vocabulary that lets defenders, vendors, and researchers all point at the same flaw. zmam.ai cross-references everything it detects against this system.

CVE (Common Vulnerabilities and Exposures): A unique identifier — CVE-2024-12345 — assigned to a specific software vulnerability so every defender, vendor, and researcher can point at the same flaw. The identifier itself does not say how serious the bug is or whether anyone has exploited it; that information comes from CVSS scores, NVD enrichment, CISA KEV entries, and vendor advisories tied to the same CVE id.
See also: CVSS, KEV, NVD.
CVSS (Common Vulnerability Scoring System): A 0–10 numerical score and a vector string describing how a vulnerability behaves: attack vector (network, adjacent, local, physical), attack complexity, privileges required, user interaction, scope, and impacts to confidentiality, integrity, and availability. A CVSS vector like AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H is more useful than the score alone: it tells you why a 9.8 is reachable over the network with no login and no user click.
See also: CVE.
KEV (Known Exploited Vulnerabilities): A list the U.S. CISA maintains of CVEs known to be exploited in the wild. A CVE on KEV is no longer a theoretical risk — someone has used it against real systems. Treat KEV entries as urgent work even when the CVSS score looks less dramatic than newer, unexploited bugs.
See also: CVE, CVSS.
NVD (National Vulnerability Database): The U.S. NIST database that enriches CVEs with CVSS scoring, affected product ranges (CPEs), references, and machine-readable metadata. Enrichment can lag the CVE record itself, so vendor advisories still matter. zmam.ai’s CVE checks query NVD’s v2 API to map detected versions to known vulnerabilities.
See also: CVE, CVSS.
PoC (Proof of Concept): Code or a request that demonstrates a vulnerability is real, without necessarily weaponising it for harm. PoCs are how researchers prove a finding to vendors and how defenders verify their patches actually closed the hole.
See also: Exploit.
Exploit: A working tool that uses a vulnerability to achieve attacker-chosen impact — code execution, data theft, privilege escalation. Different from a PoC by intent and polish: an exploit aims to succeed in the wild, often reliably and stealthily.
See also: PoC, Zero-day.
Zero-day: A vulnerability for which no patch exists at the moment of attack — the defender has had zero days to apply a vendor fix. The label describes patch availability, not whether the bug is public. The window closes as soon as a vendor ships a fix; from then on it is an “n-day”.
See also: N-day.
N-day: A vulnerability for which a patch exists but many systems have not yet applied it. The vast majority of real-world compromises ride n-days, because advisories, exploit code, and target lists become public faster than patch deployment reaches every server.
See also: Zero-day.

Identity & authentication

How a server decides who it is talking to. The schemes here protect every other security decision a system makes after the first hello.

OAuth 2.0: A protocol for delegated authorisation: a user lets an app act on their behalf at another service without sharing their password. For example, a calendar app gets permission to read your Google Calendar without learning your Google password. OAuth 2.0 by itself does not say who the user is — “sign in with Google” uses OIDC layered on top.
See also: OIDC, JWT.
OIDC (OpenID Connect): An identity layer on top of OAuth 2.0 that adds a signed id_token carrying user identity claims. OIDC is what most “log in with X” flows actually use under the hood. OAuth grants access to resources; OIDC tells the application which user authenticated and how to validate that claim.
See also: OAuth 2.0, JWT.
JWT (JSON Web Token): A signed (and optionally encrypted) JSON object passed around as an opaque string — typically as an Authorization: Bearer header. JWTs let services verify a claim without calling back to an identity provider, which is fast but means revocation is hard: short lifetimes and refresh tokens are the practical mitigation. Always validate the signature, iss, aud, and exp; never accept the none algorithm.
See also: OAuth 2.0, OIDC.
API key: A long-lived secret string a calling application sends with every request, usually in an HTTP header. Simpler than OAuth, but easier to leak and harder to revoke gracefully. Treat API keys as production secrets: keep them out of URLs and git, scope each key to the narrowest permissions, rotate on a schedule, and revoke immediately after exposure.
mTLS (mutual TLS): Both ends of a TLS connection authenticate to each other with certificates, instead of only the server presenting one. The client certificate becomes the calling service’s identity — common in service-to-service traffic inside a cluster and in bank or government APIs that need strong partner authentication.
See also: TLS.
MFA (Multi-Factor Authentication): Requiring two or more independent proofs of identity to log in: something you know (password), something you have (a hardware key or phone), something you are (biometric). The single highest-leverage account-takeover control. Hardware keys (FIDO2 / WebAuthn) resist phishing best; TOTP apps are next; SMS is weaker because phone numbers can be ported or intercepted. Any second factor is still better than password-only.
Account takeover (ATO): The attacker ends up holding a legitimate user’s credentials or session token and acts as them. Sources vary — leaked password reuse, phishing, malware on the user’s device, a server-side bug — but inside the application the traffic can look like the real user. Audit logging, anomaly detection, and step-up authentication for sensitive actions are the load-bearing defences once MFA is in place.
See also: MFA.

Mobile security

Mobile apps ship as compiled bundles anyone can download and decompile. The security work happens at runtime and in the manifest — neither of which is private.

APK (Android Package): The zip-shaped file that ships an Android application. Anyone can download an APK from the Play Store or a third-party mirror and decompile it — Android does not hide your code, strings, or asset files. Anything that absolutely must stay secret has to live on a server you control.
See also: AndroidManifest, Exported component.
IPA (iOS App Archive): The Apple equivalent of an APK. Distribution is more controlled than Android — Apple’s App Store does not let researchers download arbitrary IPAs — but a compromised device gives the same view, so the same “do not ship secrets in the bundle” rule applies.
AndroidManifest: The AndroidManifest.xml file every APK ships. It declares the app’s package name, version, the permissions it requests, and the components (activities, services, receivers, providers) it exposes — including whether each is exported to other apps on the device. On modern Android, components with intent filters must declare android:exported explicitly. The manifest is the fastest starting point for a mobile security review.
See also: Exported component, APK.
Exported component: An Android activity, receiver, service, or content provider that other apps on the same device can launch. Useful when you want apps to interoperate; dangerous when a hostile app can trigger your component with crafted input. Mark android:exported="false" everywhere it is not needed; for the rest, treat the entry point as untrusted input.
See also: AndroidManifest.
Deep link: A URL handled inside an app instead of the browser, declared in the AndroidManifest (or its iOS equivalent). Deep links are a great UX feature and a common attack vector: a malicious link can drop the user inside your app at a privileged screen, sometimes bypassing the authentication or state check that protects the normal entry path.
See also: Exported component.
Certificate pinning: The app refuses to trust any TLS certificate except a small set it expects. Pinning can block local-proxy interception, which helps against hostile networks, but it also breaks debugging, enterprise inspection, and security testing. Pin to the public key (SPKI), not a single leaf certificate, and ship backup pins plus a rotation plan.
See also: TLS.
MASVS (OWASP Mobile Application Security Verification Standard): A checklist of security controls for mobile applications, grouped by platform and category (storage, crypto, authentication, network, code quality, resilience). zmam.ai uses MASVS categories when classifying APK / IPA findings.

Cloud posture

Cloud configuration is where small mistakes scale badly. A checkbox you forgot to clear can put a database on the public internet. The terms here are the ones that show up most often in post-mortems.

IAM (Identity and Access Management): The cloud-provider system that decides who (a human user, a service, a server) can do what (read a bucket, deploy a function, change a security group). Many cloud breaches start with IAM misconfiguration: a role with *:* permissions assigned to a workload that only needs s3:GetObject on one prefix.
See also: RBAC.
RBAC (Role-Based Access Control): An access-control model where permissions are bundled into roles and roles are assigned to people or services. The Kubernetes equivalent of cloud IAM. RBAC scales better than hand-written permissions per user, but it over-grants easily if every team receives admin because narrower roles take time to define.
See also: IAM.
Public S3 bucket: An Amazon S3 bucket configured to allow anonymous reads (or, worse, writes). Source of countless breaches because the content is often customer files or backups. The same shape exists in every cloud — Google Cloud Storage, Azure Blob. Permissions should default closed; enable block-public-access controls and review every bucket whose ACL or policy mentions AllUsers, Principal: "*", or public write.
IMDSv2 (Instance Metadata Service v2): AWS’s token-based metadata-service version. Callers must send a PUT request first to obtain a session token, then include that token on later GET requests. This blocks many SSRF-to-credentials paths because simple SSRF gadgets cannot set the method or headers. Enforce IMDSv2-only on every EC2 instance.
See also: SSRF.
Security group: The cloud equivalent of a stateful host firewall. AWS calls it a security group; other clouds use similar names. A single sloppy rule — 0.0.0.0/0 on a database port — becomes a recurring source of breaches. Default deny, allow narrow source ranges, and review changes as code.
ASN (Autonomous System Number): The number identifying an entity that operates a chunk of the internet — a cloud provider, an ISP, a large enterprise. Every IP address belongs to exactly one ASN at a given time; knowing the ASN tells you whether an address sits in, say, a cloud provider, a corporate network, or a residential ISP. It does not prove ownership by itself, but it is a strong clue for routing and attack-surface triage.
See also: CIDR.
CIDR (Classless Inter-Domain Routing): A notation for a range of IP addresses: 10.0.0.0/24 covers 256 IPv4 addresses. Used everywhere from firewall rules to VPC configuration and engagement scope. The number after the slash counts how many address bits stay fixed; the rest can vary. A smaller slash number means a larger range.

Reconnaissance & attack surface

Before any exploit there is a survey. These are the building blocks attackers and defenders both use to map what is reachable from the outside.

Attack surface: The full set of points an attacker could try as a way in or out. Internal attack surface includes employees, laptops, and lateral movement paths; external attack surface — the part zmam.ai measures — is everything an outsider can reach: your domains, subdomains, certificates, exposed services, mail configuration, and any artifact you have published (app stores, git repos, JavaScript files).
See also: EASM.
EASM (External Attack Surface Management): The discipline of continuously discovering and reviewing everything an organization exposes to the public internet — so when a forgotten subdomain points at a decommissioned service, an exposed admin panel appears, or a certificate reveals a new host, you find it before an attacker does. zmam.ai is an EASM tool you can run on yourself.
See also: Attack surface.
Subdomain: A name living under your apex: api.example.com, staging.example.com. The number you have is almost always larger than the number you remember, because staging hosts, vendor portals, and old campaigns accumulate. Subdomain enumeration is usually the first pass in external recon.
Subdomain takeover: An attack that exploits a dangling DNS pointer to claim a subdomain you no longer use. The attacker registers the cloud bucket or SaaS hostname your CNAME still points at, then serves whatever they want under your subdomain — which browsers and email auth treat as yours. The fix is to delete the DNS record at the same time you delete the service.
See also: Dangling DNS, CNAME record.
Port scan: Asking each numbered port on a host whether something is listening. The output is “open / closed / filtered” per port. Modern scanners combine TCP handshakes, UDP checks, and TLS probes, run at rate limits that avoid disrupting services, and follow up with banner grabs.
See also: Banner grabbing.
Banner grabbing: Once a port is known to be open, asking the service on the other end to identify itself — most servers do, sometimes with version strings precise enough to map to a CVE. Polite scans use one or two well-formed probes per port; noisy scans try many protocol guesses and often trigger intrusion-detection alerts.
See also: Port scan.
WHOIS: The protocol that returns registration information for a domain or an IP range — registrar, registration date, name servers, and (depending on jurisdiction) registrant contact. RDAP is the modern replacement for many lookups, with a more structured format. Privacy services mask most contact details, but registration dates and name servers still tell a useful story.
Fingerprinting: Identifying the software running behind a network endpoint by the patterns in its responses — HTTP headers, default pages, TLS handshake quirks, error text, JavaScript bundles. Used to build a list of “this host is running WordPress 6.4 on Apache 2.4 on Ubuntu” so vulnerability data can answer “which of those versions are known-bad?”

Engagement & process

The vocabulary of authorised security work. Knowing which kind of engagement you are running keeps testers, owners, and lawyers on the same page.

Penetration test: An authorised, in-depth engagement in which a tester actively probes specific systems to demonstrate what an attacker could do. Time-boxed, scope-bounded, and goal-oriented: chain bugs, escalate privilege, prove impact. It is distinct from a non-intrusive external review, which only reads public signals and avoids exploitation.
See also: Red team, Responsible disclosure.
Red team: A broader engagement that includes social engineering, physical access attempts, and persistence after initial access — emulating a real adversary’s playbook rather than finding the maximum number of bugs. Often graded by whether defenders detected, investigated, and contained the activity.
See also: Penetration test.
Bug bounty: A standing programme in which a company invites independent researchers to find vulnerabilities and pays per accepted report. Scope, severity tiers, and acceptable test methods are published up front. zmam.ai users in Saudi Arabia will know BBSA; HackerOne and Bugcrowd are widely used global platforms.
See also: Responsible disclosure.
Responsible disclosure: The norm where a researcher who finds a vulnerability gives the vendor a reasonable window — often 90 days — to fix it before any public discussion. Vendors are expected to respond, ship a patch, and credit the researcher. Coordinated Vulnerability Disclosure (CVD) is the more precise formal name, because both sides coordinate timing and detail.
See also: Bug bounty.
Scope: The written agreement covering what is and is not allowed during a security engagement — which hosts, which test methods, which times, which data, and which proof is enough. Out-of-scope work is not consensual security testing; it is computer misuse, no matter the intent.
See also: Bug bounty.
BBSA (Bug Bounty Saudi Arabia): The Saudi national bug-bounty platform that hosts a curated list of programmes for KSA-based and KSA-licensed companies. Like Bugcrowd or HackerOne in form, but with KSA-specific scope, rewards, and reporting flow.

Cryptography fundamentals

Five primitives sit underneath nearly every modern security control. You do not need to implement them — you need to know what they promise and where each is appropriate.

Hash function (SHA-256): A one-way function that turns input of any size into a fixed-size fingerprint (a “digest”). SHA-256 produces a 32-byte digest, commonly shown as 64 hex characters. Used to fingerprint files, sign content indirectly, and detect tampering: change one byte in a file and its SHA-256 digest changes unpredictably. Older hashes — MD5 and SHA-1 — are still seen but should be retired wherever collision resistance matters.
HMAC (Hash-based Message Authentication Code): A scheme that combines a hash function with a shared secret key to produce a tag that proves the message came from someone holding that key and was not altered. Standard for signing API requests, webhook payloads, and session cookies: recompute the tag with the shared secret and compare it before trusting the payload. HMAC-SHA-256 is the safe default.
AES (Advanced Encryption Standard): The bulk symmetric cipher behind nearly every modern secure protocol. AES-128 and AES-256 are both safe in their AEAD modes such as GCM; the older CBC mode is fragile without an additional MAC and careful padding handling. Pick AES-GCM unless you have a specific reason not to, and never reuse a GCM nonce with the same key.
See also: Authenticated encryption (AEAD).
Authenticated encryption (AEAD) (Authenticated Encryption with Associated Data): A combined construction that encrypts and authenticates in one pass. The ciphertext is unreadable to anyone without the key, and tampering with even one bit makes decryption fail cleanly. Associated data, such as a record type or sequence number, is authenticated but not encrypted. AEAD is the right default for any new design; separate encryption-plus-MAC schemes are easier to get wrong.
See also: AES.
Key rotation: The practice of replacing a cryptographic key on a schedule or after suspected exposure so that a stolen key has a bounded blast radius. Plan for rotation from the start: include key identifiers, accept old and new keys during the cutover, then retire the old key once every client has moved.