Authentication
Confirming who a user or system is, usually with a password, passkey, single sign-on or token.
Authentication answers "who are you?". In a web application it covers sign-in, multi-factor prompts, password reset, session creation and API tokens. Testing looks at whether those steps can be skipped, repeated, guessed or reused in ways the designers did not intend. Authentication is often confused with authorization, which decides what a signed-in user may do. Many serious findings sit in the gap between the two, where a user is correctly identified but then allowed to act on data that is not theirs.
Related:AuthorizationSSO, SAML and OIDCSession management
Authorization
Deciding what an authenticated user or system is allowed to see and do.
Authorization answers "are you allowed to do this, to this object?". It includes role checks (can a member change billing settings?) and ownership checks (does this invoice belong to your organisation?). Authorization flaws are among the most common and most damaging issues in modern web applications and APIs because each endpoint has to make the decision correctly. Testing uses a role matrix and multiple test organisations to check every sensitive action from every role.
Related:AuthenticationBroken object level authorization (BOLA / IDOR)Tenant isolationRole matrix
Black, grey and white box
How much information and access the tester has, from none (black) to full source code (white).
Black-box testing starts with no inside knowledge, like an outside attacker. Grey-box testing adds test accounts and documentation, which is the most common choice for web applications and APIs because it reaches authenticated features efficiently. White-box testing adds source code and architecture access, which finds design issues faster but takes more preparation. More access usually means better coverage for the same effort; it does not make a test less realistic.
Related:Penetration testScope record
Broken object level authorization (BOLA / IDOR)
An API returns or changes an object without checking that it belongs to the caller.
BOLA, also called insecure direct object reference (IDOR), happens when an application trusts the identifier in a request instead of checking ownership. A signed-in user changes an invoice or document ID and receives someone else's record. It is the first item in the OWASP API Security Top 10 (2023) because it is common and easy to miss in code review. The fix is to scope every data lookup by the caller's tenant or ownership in the data-access layer, and to test for it automatically.
Related:AuthorizationTenant isolationOWASP API Security Top 10
CVSS
The Common Vulnerability Scoring System, a standard way to describe and score technical severity.
CVSS (currently version 4.0) describes a vulnerability with a vector of characteristics, such as how it is reached and what it affects, and produces a score from 0 to 10. It is widely recognised and useful for consistency, but it does not know your business context. ZenoPentest uses CVSS as an input to severity and writes a rationale for the final rating.
Related:Severity
False positive
A reported issue that turns out not to be a real, exploitable weakness.
False positives are common in automated scanner output and waste engineering time. In a penetration test, every reported finding should be confirmed manually and backed by evidence, such as a request and response, so engineers can see it for themselves. Where something cannot be confirmed, it belongs in the report as an observation, not as a finding.
Related:Vulnerability scanSeverity
ISO/IEC 27001
An international standard for information security management systems, certified by accredited bodies.
ISO/IEC 27001 sets requirements for how an organisation manages information security risk. Certification bodies audit against it. Technical testing such as penetration testing is often used as evidence that controls work and that vulnerabilities are managed. As with SOC 2, a pentest report supports certification work but is not certification itself.
Related:SOC 2
Mass assignment
An API accepts and saves fields the user should not be able to set, such as their own role.
Frameworks can bind an entire request body to a data model for convenience. If the model includes sensitive fields, such as role, account status or price, a user may be able to change them simply by including them in a request. The fix is an explicit allow-list of editable fields for each endpoint. OWASP groups this under broken object property level authorization.
Related:OWASP API Security Top 10Authorization
OAuth scope
The set of permissions an application is granted when a user connects it to another service.
OAuth lets one application act on a user's behalf in another, such as reading a calendar or posting to a workspace. Scopes define what it may do. Problems arise when integrations request more scope than they need, store tokens carelessly or apply one customer's tokens to another customer's data. Integration reviews check requested scopes, token storage and how tokens are tied to tenants.
Related:SSO, SAML and OIDCTenant isolation
OWASP API Security Top 10
A ranked list of the most common and serious API security risks, last updated in 2023.
The API Security Top 10 highlights risks that are particularly common in APIs, led by broken object level authorization and broken authentication, and including excessive data exposure through properties, missing resource limits and unsafe consumption of other APIs. It is a useful checklist for API scope, though a real assessment goes further than any top-ten list.
Related:Broken object level authorization (BOLA / IDOR)Mass assignmentOWASP ASVS
OWASP ASVS
The OWASP Application Security Verification Standard, a detailed list of application security requirements.
ASVS (version 5.0) describes what a secure web application should do, chapter by chapter, from authentication and session management to access control and data protection. It is useful for agreeing test depth and for engineering teams that want a target to build towards. ZenoPentest maps test areas to ASVS chapters so reports can be compared with that standard.
Related:OWASP WSTGOWASP API Security Top 10
OWASP WSTG
The OWASP Web Security Testing Guide, a public catalogue of how to test web applications.
The Web Security Testing Guide organises web testing into categories such as identity management, authentication, authorization, session management, input validation and business logic, each with named tests. It is a common shared reference for testers and buyers. Mapping a report to WSTG categories helps a reviewer see which kinds of testing were performed.
Related:OWASP ASVSPenetration test
Penetration test
A time-boxed, largely manual assessment in which a tester tries to find and prove real security weaknesses.
A penetration test examines an agreed scope as an attacker would, but with permission and a written method. For web applications and APIs that means testing authentication, authorization, business logic, input handling and integrations by hand, using tools to support rather than replace judgement. The output is a report with evidence for each finding, its impact and how to fix it. It differs from a vulnerability scan, which is automated and does not understand business logic.
Related:Vulnerability scanPTaaS (pentest as a service)Retest
Prompt injection
Text that causes an AI model to ignore its instructions, either typed by a user or hidden in content it reads.
Large language models follow instructions found in their input. Direct prompt injection comes from the user; indirect prompt injection is hidden in documents, web pages or emails the model retrieves. The real risk depends on what the application lets the model see and do. An assistant with access to private data or tools needs boundaries that hold even when the model is misled. The OWASP Top 10 for LLM Applications lists it first.
Related:Tool authority (AI agents)
PTaaS (pentest as a service)
Penetration testing delivered through a platform with ongoing access, dashboards and repeat testing.
Pentest-as-a-service providers combine human testing with a platform for scheduling, live findings and retests, usually sold on subscription or credits. The model suits organisations that test frequently. A project-based assessment suits teams that need one well-scoped test with a report for a specific release, customer or audit. Both can be good; what matters is the depth of manual testing in the agreed scope.
Related:Penetration testRetest
Retest
Checking that reported findings have been fixed, and recording the result.
After the report, your engineers fix issues and ask for them to be verified. A retest repeats the original test for each fixed finding and checks that the fix did not break legitimate access. Results are recorded in the verification ledger with dates. Reviewers often ask for this, because a report full of open high-severity findings raises more questions than it answers. The number of retest rounds and their timing are agreed in the proposal.
Related:Verification ledgerPenetration test
Role matrix
A table of roles against actions, used to test that each role can do only what it should.
A role matrix lists every role in an application (for example anonymous, member, billing admin, admin) against the sensitive actions they might take. During testing each cell is attempted, so vertical privilege problems (a member performing an admin action) and horizontal problems (one member acting on another's data) are found systematically rather than by chance. The scope record lists which roles were tested, and a good report shows the matrix so reviewers can see coverage.
Related:AuthorizationScope record
Rules of engagement
The agreed limits on how testing is carried out, such as timing, techniques and stop conditions.
Rules of engagement set the practical boundaries of an assessment, for example permitted test hours, rate limits, whether production data may be touched, which techniques are excluded (such as denial of service or social engineering) and who to call if something unexpected happens. They protect the system owner and the tester, and they sit alongside the scope record and written authorisation in the proposal.
Related:Scope recordWritten authorisation
Scope record
The written list of what was tested, with which roles, in which environment, and what was excluded.
A scope record turns "we tested the app" into something a reviewer can check. It names each asset (applications, APIs, admin consoles), the roles and test accounts used, the environment, the test window and anything explicitly out of scope. It is agreed before testing and repeated in the report. Without it, a clean report proves very little, because nobody can tell whether a risky area was tested or simply left out.
Related:Rules of engagementWritten authorisationRole matrix
Session management
How an application keeps a user signed in, and ends that state safely.
After sign-in, a session cookie or token represents the user. Good session management sets sensible lifetimes, invalidates sessions on sign-out and password change, protects cookies with secure attributes and prevents sessions being fixed or reused. Weak session handling can undo strong authentication, so it is tested alongside sign-in and multi-factor flows.
Related:AuthenticationSSO, SAML and OIDC
Severity
How serious a finding is in the context of the specific system, based on impact and likelihood.
Severity combines what could happen (impact) with how plausible it is (likelihood) for the system that was tested. A useful report explains the rating in words for each finding, so engineers and reviewers can disagree constructively. Scoring systems such as CVSS help with consistency, but the same technical flaw can deserve different ratings in different products.
Related:CVSSFalse positive
SOC 2
An audit framework for service organisations' controls; a pentest can be evidence within it, not a substitute for it.
SOC 2 reports are issued by independent auditors who assess an organisation's controls against the trust services criteria. Auditors and customers commonly look for regular penetration testing as evidence that security controls are tested. A penetration test report is that evidence; it is not a SOC 2 report, attestation or certification, and no tester can guarantee an audit outcome.
Related:ISO/IEC 27001Penetration test
SSO, SAML and OIDC
Single sign-on lets users log in through an identity provider using protocols such as SAML or OpenID Connect.
Enterprise customers expect to sign in through their own identity provider. SAML and OpenID Connect (OIDC) are the common protocols. They move a lot of security responsibility into configuration: which identity providers are trusted, how accounts are matched and linked, and how sessions are created. Integration and authentication testing checks these decisions, especially account linking and tenant boundaries.
Related:AuthenticationOAuth scopeSession management
Tenant isolation
Keeping each customer organisation's data and actions separate in a shared, multi-tenant application.
Most SaaS products serve many customer organisations from the same application and database. Tenant isolation is the set of controls that stop one customer seeing or changing another's data. Enterprise security reviewers ask about it directly. Testing creates at least two test organisations and attempts reads, writes, exports, searches and integrations across the boundary, as well as checking background jobs, webhooks and caches that may mix tenants.
Related:Broken object level authorization (BOLA / IDOR)AuthorizationScope record
Tool authority (AI agents)
The actions an AI assistant or agent is permitted to take, such as sending email or changing records.
When an AI feature can call tools or APIs, the question shifts from "what might it say?" to "what can it do, and on whose behalf?". Tool authority should follow the same authorization rules as the rest of the product, with confirmation for sensitive actions and no access beyond the signed-in user's own rights. AI application testing checks these boundaries rather than the model itself.
Related:Prompt injectionAuthorization
Verification ledger
The section of a report that records each finding's fix and retest status.
A verification ledger lists every finding with its status (verified fixed, fix pending, or accepted as a documented risk), the date of the retest and a short note. It lets a client, customer or auditor see remediation progress without reading every finding again. ZenoPentest reports update the ledger in a new report version after each agreed retest.
Related:RetestSeverity
Vulnerability scan
An automated check for known weaknesses and misconfigurations.
Scanners compare a system against large libraries of known issues, such as outdated software, missing headers or common injection patterns. They are fast and useful for continuous hygiene. They do not understand who should be allowed to do what, so they rarely find authorization, tenant isolation or business-logic flaws. A report that is mostly scanner output reformatted is not the same as a penetration test, and enterprise reviewers increasingly ask which one they are reading.
Related:Penetration testFalse positive
Written authorisation
Signed permission from the owner of a system to test it, required before any testing begins.
Testing someone's system without permission can be unlawful, so a penetration test always starts with written authorisation from the party that owns or controls the system. On an agency project that is usually the agency's client, not the agency itself. Where third parties host or operate parts of the system, their testing policies also apply. An enquiry form never authorises testing.
Related:Rules of engagementScope record