Security reports can be full of unfamiliar words. Use this guide to understand what they mean, why they matter, and what a risk could lead to.
Checking that a person or service really is who it claims to be—often with a password, passkey, or sign-in token.
It is the front door to accounts and private features.
Someone may get into an account without proving they own it.
Deciding what an authenticated person or service is allowed to see or do.
A valid login should only grant the access that user needs.
A user may reach actions or information meant for someone else.
A broad name for missing or incorrect permission checks.
Every protected page, API action, and record needs the right access check.
Users may view, change, or delete data or actions outside their permissions.
A type of access-control flaw where changing an ID in a URL or request can expose another person’s record because ownership was not checked.
APIs often identify records with IDs that users can alter.
Private records may be read or changed by the wrong user.
A sign-in that asks for two different kinds of proof, such as a password and an authenticator app code.
A stolen password alone is less likely to be enough to sign in.
An attacker with a leaked password has a simpler path into the account.
When untrusted input is treated as part of a database command instead of ordinary data.
Database queries should keep user input separate from the command itself.
An attacker may be able to read, alter, or remove data, depending on the query and permissions.
When a site shows untrusted content in a way that lets it run as code in another visitor’s browser.
A browser trusts code that comes from the site it is visiting.
An attacker may act through a visitor’s session or show misleading content.
Tricking a signed-in browser into sending an unwanted request to a site where the user is already logged in.
Browsers may automatically include sign-in cookies with requests.
A user may unknowingly trigger an action on their account.
Tricking a server into making a network request chosen by an attacker.
A server may be able to reach private services that the public cannot.
Internal services or data could be exposed if requests are not restricted.
Setting a limit on how many requests a user or device can make in a given time.
It helps keep automated or unusually frequent requests under control.
Brute-force logins, scraping, API abuse, or service overload may become easier.
A browser rule that controls which websites can read responses from another website.
It lets an API make deliberate choices about browser-based cross-site access.
An overly broad policy may allow untrusted sites to read responses in some situations. CORS does not replace authentication.
Checking that incoming data has the expected type, format, size, and allowed values.
It rejects unexpected data before the application uses it.
Malformed or hostile input may cause errors or contribute to other flaws.
HTTP response settings that tell browsers how to apply extra protections to a site.
They can reduce the impact of certain browser-based attacks.
Without the right protections, some attacks may be easier to carry out or harder to contain.
A browser rule that limits where a page can load scripts and other resources from.
It can help limit the damage from some injected content.
Without a suitable policy, injected code may have more room to run. CSP does not fix the underlying bug.
The encrypted connection used when a browser communicates securely with a website.
It helps prevent others on the network from reading or changing traffic in transit and helps verify the site.
Unprotected traffic may be exposed or altered while it travels.
Database rules that decide which individual rows a user or service can read or change.
It adds access checks close to the data itself.
A missing or incorrect policy may let one user access another user’s records.
A password, API key, token, or other credential written directly into source code or a checked-in config file.
Code is often shared, copied, or stored in version history.
Anyone who obtains the secret may use it until it is revoked or expires.
Turning readable information into a protected form that can be read only with the right key.
It helps protect sensitive data while stored or, with a secure connection, while sent.
If sensitive data is left unprotected, someone who gains access to the storage or traffic may read it.
A known security weakness in a third-party package your application uses.
Applications inherit some of the risks in their libraries and tools.
An attacker may exploit the weakness if your app uses the affected code in a reachable way.
Reviewing source code without running the application to look for risky patterns.
It can point developers to code that may need a closer look early in development.
If risky code goes unnoticed, a weakness may reach a deployed application. A result still needs context.
Testing a running application from the outside, often by sending requests and observing responses.
It can reveal issues in behavior that are visible when the app is running.
A live weakness may remain undiscovered. DAST also cannot see every code path.
A security alert that looks like a problem but is not a real vulnerability in the application’s actual context.
Automated tools can lack the context a developer has.
Teams may waste time or lose trust in useful findings if alerts are not checked.
Security terms describe possible risks. Confirm each finding against your code, configuration, and how the application is used.