10 Security Acronyms Every Developer Must Know

The days where security testing is carried out in a penetration test by your security team or a third party firm, are increasingly becoming a thing of the past. Today, developers are leading the charge, as we “shift Left” with ”AppSec testing for developers”.

With DevSecOps and CI/CD, security testing now sits at multiple stages of the development pipeline, especially with developer first application security tools, with conversations about security being held regularly. 

As a developer though, what the hell are all these abbreviations and cybersecurity acronyms that security folk love to use and expect you to know?

As our application security testing tool is widely and increasingly used by developers (you can sign up for a free account here), our ongoing support includes hands-on workshops, where it became very apparent that keeping up with new technologies and their acronyms, as well as getting to grips with common security and vulnerability parler, is a tough ask for many developers.

So, to help you along the way, we’ve put together this cheatsheet of our top 10 most common cybersecurity acronyms – hope it helps, LMKWYT (let me know what you think)

1. DAST – Dynamic Application Security Testing
2. SCA – Software Composition Analysis
3. SAST – Static Application Security Testing
4. OWASP – Open Web Application Security Project
5. XSS – Cross-Site Scripting 
6. CSRF – Cross-Site Request Forgery
7. SQLi – SQL Injection
8. XXE – XML External Entity
9. SSRF – Server Side Request Forgery
10. Security Champion

1. DAST – Dynamic Application Security Testing

Dynamic Application Security Testing (DAST), like Bright, is an Application Security Testing methodology in which the application is analysed and tested in operating mode, from the outside-in. As DAST tools don’t have access to the application and API source code, they detect vulnerabilities by performing actual attacks, similar to a real hacker.

Therefore, DAST solutions are a perfect fit if you want a better insight into how your web applications and APIs behave in production. While code scanning is an important part of the process of making your applications more secure, code scanners have many limitations. In addition to having a very high rate of false-positives and being limited to specific development languages and frameworks, some vulnerabilities only exist in the runtime environment, and if you don’t utilize a DAST tool, they will be missed. This is particularly relevant to microservice based architectures, which are becoming the norm.

DAST has typically been performed late in the testing phases, typically just before an application or service is deployed to a production. With a DAST like Bright’s, you can integrate this into the CI/CD, to enable developers to scan each build/commit early and detect and remediate security risks before they become serious. With Bright’s NO false positive reporting, developers can trust the output and start fixing issues!

2. SCA – Software Composition Analysis

SCA is a widely used form of developer application security testing, which identifies security vulnerabilities in your 3rd party dependencies. Run throughout the development pipeline, SCA builds the open source dependency trees for your applications and maps these against a database of known vulnerabilities. It then reports vulnerable open source that has been pulled into your application, to fix or patch accordingly.

SCA is very complimentary to DAST, where running a check on your dependencies and a dynamic test delivers considerable security testing coverage. Read here how you can complete your appsec testing automation with Bright and Snyk

3. SAST – Static Application Security Testing

Static Application Security Testing, or SAST, analyses the source code of an application to detect security vulnerabilities that may exist. SAST is an automated tool that looks for vulnerabilities in newly developed code, carried out during the coding stage. It does this by searching for coding patterns, insecure functions or objects that may lead to security vulnerabilities.

Although SAST can detect vulnerabilities early in the development process, you will notice that the word “may exist” or “may lead to” are used frequently when referring to SAST results. This is because SAST tools generate a large number of false positives. This requires a considerable amount of fine tuning to reduce these and to be more accurate.

What are the differences between SAST and DAST? Check-out our SAST vs. DAST blog.

4. OWASP Top 10

Everyone in security talks about The Open Web Application Security Project, or OWASP. It is a non-profit that works tirelessly to improve the security of software, led by a global community of open source software projects and chapters, to deliver educational and training conferences to guide you on how to produce more secure software.

The most prominent of OWAP’s projects is the ‘OWASP Top 10’. This lists the ten most common types of web application vulnerabilities, updated by the community. 

As a developer, you will regularly hear that the security tool you are using, such as your SAST or DAST, will cover this list. It is not comprehensive, but adopting and testing for this list will minimise your risks as an effective way of enhancing your security culture to produce secure product. Bright’s DAST has you covered here.

With APIs now more prevalent than ever, there is also the OWASP API Top 10. We ran a poll on how mature API security testing processes are in organisations and how often they test their APIs for security vulnerabilities – see the results here. With many security testing tools not able to test APIs, this was typically carried out manually or not at all. Ensuring your DAST tool can test APIs is very important, something NeuraLegoin has full support for, to cover SOAP, REST and GraphQL based API security testing.

For more info, see our post on The Rising Importance of API Security

5. XSS – Cross-Site Scripting

Cross-site scripting (XSS) is a common and dangerous type of attack that plagues almost all web applications, be it older or modern ones. Having been included in the OWASP Top 10 since its inception, it relies on developers using javascript to enhance the experience of end-users of their application, but when the javascript isn’t properly handled it leads to many possible issues, and one of them is XSS. This allows an attacker to execute malicious (usually) javascript code within a user’s browser, to steal sensitive information.

There are three main forms of XSS:

Reflected XSS: This is where the attacker makes the unsuspecting user send a request to the application that contains a payload and the application includes this in the response, causing it to be executed within the browser.

Stored: Where the attacker sends the payload to the application, which is stored in a value that is returned to the user (or users) resulting in the script / payload executing within their browser.

DOM-based XSS: Document Object Model-based Cross-site Scripting. This kind of XSS attack occurs when an application receives some client-side JavaScript that processes data from an unsafe, or untrusted source by writing the data to a potentially dangerous sink within the DOM instead of writing data in HTML which would present a regular XSS.

Learn more on in our article on “The Ultimate Beginners Guide to XSS Vulnerability” and how you can mitigate this common security issue

6. CSRF – Cross-Site Request Forgery

Cross-site Request Forgery (CSRF/XSRF), also known as Sea Surf or Session Riding is a web security vulnerability that tricks a web browser into executing an unwanted action. An  attacker can abuse the trust that a web application has for the victim’s browser. It allows an attacker to partly bypass the same-origin policy, which is meant to prevent different websites from interfering with each other.

When a website sends a data request to another website on behalf of a user along with the user’s session cookie, an attacker can launch a Cross-Site Request Forgery Attack, which abuses a trusting relationship between the victim’s browser and the webserver.

In some cases, an attacker can gain full control of the user’s account or worse, full control of all the application’s functionality and data, if the user has privileged access. The result can be data theft, unauthorized fund transfers, damaged client relationships, changed passwords and many more.

For detailed information, see our blog on Cross-Site Request Forgery and how to prevent CSRF Attacks.

7. SQLi – SQL Injection

Again, a staple on the OWASP Top 10, SQL injections represent a code injection technique used to attack applications and the data they hold. They usually occur when user input is required, for example, username, but the user gives an SQL statement instead.

To make an SQL injection attack, an attacker must first find vulnerable user inputs within the web page or application. When the attacker creates input content and sends it, malicious SQL commands are executed in the database. This way an attacker can gain complete control over the affected database.

There are many types of SQL injection attacks, whether they are user input triggered, or second-order SQL injection attacks. Common ones include:

1. Union-based SQL Injection
2. Error-Based SQL Injection
3. Blind SQL Injection, which can include
   1. Boolean-based SQL Injection
   2. Time-based SQL Injection

For more detailed information on SQL injection, read our article on What Are SQL Injections and How Can They Be Prevented.

8. XXE – XML External Entity

What’s your XXE-cuse..? Another one of the OWASP Top 10, XML external entity (XXE) attacks are targeted against applications that parse XML input. They exploit weakly configured XML parsers, which process XML code that references external entities. XXE attacks can result in port scanning within the internal network, server-side request forgery (SSRF), data exfiltration, use of an organization’s servers to perform denial of service (DoS), and more.

For more info, delve into our blog on Understanding XXE: Attack Types and Prevention Methods

9. SSRF—Server Side Request Forgery

Server-Side Request Forgery (SSRF) attacks allow an attacker to make requests to any domains through a vulnerable server. Attackers achieve this by making the server connect back to itself, to an internal service or resource, or to its own cloud provider.

Attackers exploiting SSRF vulnerabilities can abuse any user inputs that accept URLs or file uploads, causing the server to connect to malformed URLs or external resources..not good!

There are several impacts of an SSRF server side attack that can be very damaging. To read more about these, the three main types of SSRF attacks that cause them and more importantly how to prevent them, read our blog post on 3 Types of SSRF Attacks and How to Prevent Them

10. Security Champion

OK, I concede, this one isn’t an abbreviation or a cybersecurity acronym, but it is a term that is quite rightly becoming more common. 

A security culture is very important for a successful DevOps and AppSec programme. To succeed, security needs to be top of mind for everyone across your pipeline. 

You as developers, QA and security teams must have a close working partnership to break down silos and improve security knowledge.

One effective way to achieve this is to create security champions to act as the voice of security across your teams.

Are you the perfect security champion that can help bridge this gap, by evangelizing, managing and enforcing the security posture with your development team(s) acting as an extended member of the security team?

Learn more about the responsibilities of a security champion and how to get your AppSec program kicked off here

You’ve Got the Lingo….Now Start Automating your AppSec Testing

Security has many technical terms and the ones above merely scratch the surface. Terms get thrown around which can make conversations confusing for developers. Additionally, application security tools compound the matter by being built for security experts and not developers, who are supposed to be using them now as part of their pipeline.
For a developer friendly, intuitive and accurate DAST scanner (NO false positives), try Bright for free by signing up here. We also provide developer focussed remediation guidelines for every finding detected. We speak your language so you can understand the issue and how to fix it. If the lingo gets too confusing (and for continued support by our security engineers), reach out on our Discord and we’ll soon have it translated for you!

Subscribe to Bright newsletter!