Security glossary: 40 terms in one sentence each
The forty security terms a business owner meets in audits, incident reports and client questionnaires, each explained in one plain sentence.
The short answer
Security has a vocabulary shared by suppliers, auditors, insurers, journalists and attackers, and a business owner who knows it can read a vulnerability report, a client questionnaire or a news story about a breach and understand what is actually being said. The forty terms below are the ones that come up most, each in one plain sentence. They fall into five groups: kinds of attack, kinds of weakness, protections, processes and evidence. When a term is used to sell a product, ask which weakness it addresses and whether your site has that weakness; the answer is often that a static site behind a network layer does not.
Kinds of attack
| Term | In one sentence |
|---|---|
| Phishing | A message that impersonates someone trusted to get a person to reveal a password, approve a payment or click something harmful. |
| Credential stuffing | Trying username and password pairs leaked from one service against many others, relying on people reusing passwords. |
| Brute force | Guessing passwords or codes by trying many possibilities automatically, stopped by rate limits and second factors. |
| Denial of service | Flooding a site with traffic so real visitors cannot get through, absorbed by a network layer in front of a static site. |
| Injection | Sending input that a system mistakenly runs as a command or query, such as SQL injection against a database. |
| Cross-site scripting | Getting a site to show an attacker’s script to other visitors, who then run it with their logged-in session. |
| Cross-site request forgery | Tricking a logged-in user’s browser into performing an action on a site without their intent. |
| Session hijacking | Stealing the token that proves a user is logged in and using it as them. |
| Supply chain attack | Compromising a package, plugin or service a site depends on, so every site using it inherits the compromise. |
| Subdomain takeover | Claiming a service that a forgotten DNS record still points at, and serving content under your domain. |
| Business email compromise | Taking over or impersonating a business email account to redirect payments or extract data. |
| Ransomware | Encrypting a business’s data and demanding payment for the key, defeated by tested backups stored elsewhere. |
Kinds of weakness
| Term | In one sentence |
|---|---|
| Vulnerability | A flaw in software or configuration that could be used to cause harm. |
| Broken access control | A flaw where users can reach data or actions they should not, the most common finding in application audits. |
| Misconfiguration | A setting left insecure: default credentials, open storage, verbose errors, missing headers. |
| Outdated dependency | A package or plugin with a known vulnerability that has not been updated. |
| Exposed secret | An API key, password or token stored where others can read it, such as in code or a public repository. |
| Insecure file upload | An upload feature that accepts files it should not, letting an attacker place executable content on the site. |
| Attack surface | Everything an attacker could interact with: every endpoint, input, account, plugin and integration. |
| Zero-day | A vulnerability being exploited before a fix exists, which is why layered defences matter. |
Protections
| Term | In one sentence |
|---|---|
| Two-factor authentication | Requiring a second proof of identity beyond the password, the single most effective control against account takeover. |
| Least privilege | Giving every person, key and system only the access it needs and nothing more. |
| Encryption in transit | Protecting data as it travels, through HTTPS, so it cannot be read or altered on the way. |
| Encryption at rest | Protecting data as stored on disk, so a stolen drive or a copied backup file reveals nothing. |
| Security headers | Instructions a site sends to browsers that switch on protections against scripting, framing and downgrade attacks. |
| Content security policy | A header that lists where a page may load scripts and resources from, so an injected script fails to run. |
| Rate limiting | Capping how many requests one source can make, so guessing and flooding are stopped. |
| Web application firewall | A filter in front of a site that blocks requests matching known attack patterns. |
| Input validation | Checking every submitted value on the server against what is expected before using it. |
| Output escaping | Encoding data before displaying it so it is shown as text and never run as code. |
| Secret storage | The platform feature that holds keys and passwords encrypted and provides them only to the running system. |
| Sandboxing and isolation | Keeping components separate so a compromise of one does not reach the others. |
Processes and evidence
| Term | In one sentence |
|---|---|
| Vulnerability scan | Automated checking of a site for known patterns of weakness, cheap and frequent. |
| Penetration test | A skilled person, with permission and a scope, trying to break in the way an attacker would, and reporting what they found. |
| Severity and exploitability | How bad a finding could be and how practical it is to use, which together decide fix order. |
| Patch management | The routine of applying updates within defined times after vulnerabilities are announced. |
| Incident response | The planned actions when something goes wrong: contain, assess, notify, recover, learn. |
| Logging and monitoring | Recording what systems did and watching for signs that something is wrong. |
| Security questionnaire | A client’s structured set of questions checking that a supplier will not become their incident. |
| Data breach notification | The legal duty to inform a regulator and sometimes affected people when personal data is exposed, within set deadlines. |
Using the glossary
- Read any security report with the glossary open and place each finding in a group: attack, weakness, protection, process or evidence.
- For each weakness named, ask whether your architecture has it; a static site has no database to inject into and no server code to run uploaded files.
- For each protection sold, ask which weakness it addresses and where it runs, inside the site or outside it.
- For each process, ask when it last happened and what the evidence is.
What this means for you
Forty terms cover almost every security conversation a small business has. Knowing them lets you read reports and questionnaires for what they say, judge products by the weakness they address, and ask precise questions of suppliers. Attackers use the same vocabulary; so should the people deciding how to keep them out.
Frequently asked questions
Which terms matter most for a small business owner?
Phishing, because it is the leading way attackers get in, and credential stuffing, because it follows from reused passwords; two-factor authentication, because it stops both; access control, injection and cross-site scripting, because they are the most common flaws in applications; dependency and supply chain, because they are how modern sites inherit vulnerabilities; and incident response, because what you do in the first hour decides the cost.
A report used a term that is not here. What should we do?
Ask the author to explain it in a sentence and to say what it means for your site specifically. Good security professionals do this readily. If the explanation is vague or the relevance unclear, the term may be padding a report or justifying a product.
Why do some of these terms sound like marketing?
Because security products are marketed with the same words engineers use, stretched to fit what is being sold. Zero trust, next generation and military grade describe intentions or nothing at all. The definitions here describe what the thing is. Where a supplier's usage differs, ask which specific weakness their product addresses and whether your architecture has it.
Sources
- ENISA Threat Landscape 2025 (accessed 2026-09-14)