Appsec Glossary


Application security posture management (ASPM) automates the identification of software assets as well as the tracking and scheduling of all application security tools and processes. ASPM approach offers a systematic process to accomplish maturity in application security. ASPM is used to gain visibility on application assets, regardless of their infrastructure. It simplifies complex workflows while collecting mission critical data, and governing a sustainable, unified software security process across the organization.

Bot Mitigation

Bot Mitigation refers to efforts designed to identify and stop non-human based activity in web applications. While some bots are considered “good” and may be in the interest of the web developer like various SEO bots, some bots and botnets are being used by malicious actors to perform malicious activities like scraping data from web applications, performing DoS (Denial of Service) attacks, or automated abuse of resources for spam attacks, sextortion, or crypto-currency mining. Examples for bot mitigation include client behaviour analysis, bots requests signing, rate limitation, and CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) challenges.

Bug Bounty

Security Bug Bounty (sometimes referred to simply as Bug Bounty or BB) refers to programs that allow responsible disclosure of security vulnerabilities, most times in exchange for a monetary reward or acknowledgment in the form of reputation. Security bug bounty programs can be public (open for anyone to submit a security report of a finding) or private (restricted for specific security researchers or invite-based upon reporting). Usually a security bug bounty program is private or public according to the availability of resources of the maintaining security team. Security bug bounty programs can be externally managed by a bug bounty management platform like HackerOne or BugCrowd. Maintaining a bug bounty program is considered best practice as it allows to extend the application penetration testing resources with real-world researchers, while the maintainer determines the security attention by determining the security bug bounty policy and rewards.


Automatic Dynamic Application Security Testing (DAST) refers to security tests that are performed at the application level by building/executing the application and reviewing the application build/runtime environments. The build/runtime can be tested in various ways such as reviewing the resources that the application is accessing in build/runtime and verifying if it is compliant to a given policy, or appropriate to the application declarations.  Another way to dynamically test the application is by fuzzy testing - running the application with unexpected inputs and known malicious payloads while reviewing the application behaviour and output to assess if it is vulnerable.

Automated DAST can be used as an automotive security tool as part of the CI pipeline as well as continuous automation over production environments.


Insecure direct object reference occurs when a software uses a user-provided reference key without properly checking permissions. For example, a system that directly reads an “account id” reference from a logged-on user, without making sure that the user is allowed to access the specified account, will be vulnerable to IDOR. Common methods to avoid such issues include implementing authorization checks, or mapping the reference keys (per session, or per user, on the server side), so that the keys used by the user represent a temporary indirect reference.

OWASP Top 10

The Open Web Application Security Project (OWASP) is an open group dedicated to Web Application Security, as part of the research of the project the group publishes a list of the most common web application security vulnerabilities. This list is a basic resource for outlining the basic risks web applications are exposed to, as well as to review trends in common vulnerabilities and attacks over time.

Penetration test

Penetration test is a dedicated custom set of automatic and manual tests performed by a security expert (the Penetration Tester) built for a specific ad hoc application security testing, usually after the application is fully developed. The penetration test is designed to check the security maturity of the system and to discover weaknesses and vulnerabilities that require mitigation. Usually the penetration test will result in a PT report detailing the weaknesses and vulnerabilities discovered, along with risk analysis of each finding and recommendation for mitigation. Penetration tests can be white box (where the penetration tester has access to internal data like the architecture design or source code of the application) or black box (where the penetration tester has no internal data of the application). Some standards (like PCI compliance standard) define requirements for the penetration tester qualifications and other penetration testing methodologies standards and requirements.


Remote code execution (RCE) is the ability of an attacker to remotely execute arbitrary code on the application server and access its resources. Remote code execution can stem from a variety of defects including memory corruption, missing input validation, and failure to restrict access to sensitive functions.

Red Team

Red team is a common name to describe an external security exercise for breaching organization security measures with no internal knowledge and no specific application scope. The concept is that the red team simulates a real threat actor targeting the organization, from determining the attack surface and selecting the attack vector, to the proof of concept of sensitive data access/leakage or disruption of business processes.

Runtime protection and detection

Runtime protection and detection refers to all efforts for the detection of malicious activities and protection of the organization resources from malicious activities. Malicious activities can be attempts to cause harm to the organization (e.g. Denial of Service, breaching systems and data harvesting), or abuse of the application resources to perform fraud, spam, crypto-currency mining, etc.


Automated Static Application Security Testing are automation tests that review the code base for vulnerabilities, usually as part of the CI pipeline or locally via an IDE integration of a SAST tool. For example, base code is checked for mishandling of user input that could allow template injection or sql query injection. SAST tools may also suggest the developer mitigation solution like deserializing untrusted user input.


Automated Software Composition Analysis (SCA) includes scanning and evaluating code dependencies (usually open-source) for known vulnerabilities and licensing.

This process is applicable to composers and dependency managers such as Docker Compose, Maven, NPM Bazel and pip.

SDLC & SDLC touch points

Secure development lifecycle is a discipline that focuses on properly conducting security activities at key stages of development.


Server Side Request Forgery is a server attack that refers to the ability of an attacker to perform network calls originating from the application server. Usually such attacks can result in restricted internal network resources access, not exposed to public networks, or the exposure of internal information disclosure as part of the server-request, like a server authorization token. As more and more applications move to cloud-based architecture the SSRF attacks are becoming more generic, and usually impose a high or critical security risk.

Threat modeling

A methodology for reviewing and assessing security threats in an ordered fashion avoiding security “blind spots”, usually performed as part of the design phase, but can be performed at a later stage. Threat models assist in both the discovery of unnoticed security risks and in reviewing the known issues mitigation plans. Threat modeling should be performed at an early stage of the development process, usually as part of the architecture design review phase.

Examples of threat modeling methodologies: STRIDE, attack trees, CIA.


Web App and API Protection (WaaP) is a collective name for solutions that offer both web application and API protection from various attack vectors by combining bot detection and mitigation, and inspection of API requests. An example is inspecting the parameters the client sends in the request and identifying invalid/non-legitimate parameters and blocking such invalid requests from getting to the application service.

Weaknesses & Vulnerabilities

Weaknesses and vulnerabilities are both states that indicate security risks. While weakness refers to an application error or bug, it may escalate to a vulnerability in cases where it can be exploited to perform a malicious action. The difference between a weakness and a vulnerability is the availability of a specific payload allowing it to be exploited. Once an exploit is available it is considered a confirmed vulnerability and as such it holds greater risk to the application security.


Cross-Site-Scripting (XSS) is a client attack that manipulates an Web client (for example, a web browser) to run a malicious customized script leveraging access to resources available by the attacked web application, like the ability to perform an API call as an authenticated user, or change any client resource in the web page document to manipulate the user to perform unwanted actions by a seemingly trusted source.

Back to topBack to top

AppSec, but so much

Reclaim AppSec