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
11. You’ve Got the Lingo….Now Start Automating your AppSec Testing

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!

Learn what is the purpose of SOAP APIs, how they function, the main difference between REST and SOAP APIs, and what you can do to prevent the 7 most common SOAP API vulnerabilities.

In this article, you will learn:

• What are SOAP APIs
• What is SOAP Security?
• The Difference Between SOAP and REST APIs
• Top 7 SOAP API Vulnerabilities and How to Prevent Them
  • SOAP Injections
  • SOAP Action Spoofing
  • SAML Vulnerabilities
  • Replay Attacks
  • Cross-Site Scripting
  • Broken Access and Authorization
  • Denial of Service (DoS)
• SOAP Security Best Practices: Preventing SOAP Security Threats
  • Input Validation
  • Access Control
  • Implement Authentication for SOAP APIs
  • Enable SAML Authentication
  • Ensure URLs Never Contain API Keys
• Automating SOAP Security with Bright

What are SOAP APIs?

Simple Objects Access Protocol (SOAP) originated in 1998. It’s a web communication protocol that was designed for Microsoft. Nowadays SOAP is used to send data over both HTTP and HTTPS. However, SOAP isn’t limited to just those protocols. SOAP supports XML data format only. Preset standards like a set of encoding rules, messaging structure, and a convention for granting procedure requests and responses are standard practice for SOAP. 

SOAP data format

Unlike REST APIs, which support both JSON and XML, SOAP only supports XML both for requests and responses.

SOAP messages follow a standardized structure as well. Why are SOAP API requests and responses considered heavy? Because they appear as enveloped messages. Each message is made out of four elements that have unique functions for each one:

• Envelope. The core element of all messages. It tags start and end messages, enveloping it in a sense.
• Header. The header is an optimal element. It defines extra requirements like authentication.
• Body. Contains the data needed to process the request or the appropriate response to the user.
• Fault. Another optional element. Showcases data about errors that can appear throughout API requests and responses.

WS standard protocols

SOAP can also be extended with WS standard protocols. SOAP on its own already provides basic structural elements for messages. But it doesn’t direct the things that go into bodies and headers. Standard protocols augment the main protocol. They specify how you do particular things. WS- is the mark of these protocols and WS-Security is an example. 

WSDL documents

Another important SOAP API feature is the use of WSDL documents. WSDL documents are XML descriptions of a web service that SOAP APIs continually use and are the abbreviation of web-service-communication guidelines. They describe all processes that exposed applications can perform and they define endpoints. This includes data types that are used inside SOAP messages and any action that’s available through the web service. WSDL file services act like signed contracts between servers and clients.

What is SOAP Security?

SOAP security includes strategies and practices for preventing unauthorized access to SOAP messages and user information, tampering with SOAP APIs, and disruption of normal operations. Web Standard Security (WS Security) is a key element in ensuring SOAP security.

WS-Security is a set of principles/guidelines for standardizing SOAP messages using authentication and confidentiality processes. WSS-compliant security methods include digital signatures, XML encryption, and X.509 certificates. XML encryption prevents unauthorized users from reading data when accessing it.

While WS-Security provides enhanced security controls that are built into many SOAP APIs, organizations still need to set up these controls correctly, and ensure they cannot be bypassed. Critical SOAP security practices include input validation and sanitization, ensuring access control, and configuring authentication for all API endpoints, as well as for SAML-based single sign on (SSO) systems.

Are SOAP APIs More Secure than REST APIs?

The short answer is yes, SOAP APIs are more secure. To understand why, let’s explore the differences between these two types of APIs.

SOAP is a format used for message exchange. REST, on the other hand, is an architectural style. REST Sample Implementations use JSON over HTTP. SOAP Sample Implementations use XML over SOAP over HTTP. 

The REST architectural structure focuses on using HTTP Transport. SOAP focuses on restricting your message structure:

• When it comes to the Data Exchange Format, SOAP is always SOAP-XML. This XML includes an envelope, a header, and a body.
• REST always uses HTTP as a transport protocol. REST also uses HTTP features like Response headers, Response, Request methods, etc.

In regards to the Message Interchange Format, SOAP uses the SOAP XML format for Request and Response. REST doesn’t need a fixed format. It’s the same thing for Service Definitions. SOAP uses WSDL while REST doesn’t have a standard service definition language. When we’re talking about Transport, SOAP doesn’t restrict the transport protocol that’s used. Both HTTP and MQ are available. REST utilizes the HTTP Transport Protocol.

To summarize the differences:

• SOAP services offer more comprehensive security measures, but REST services are much easier to implement. 
• SOAP needs you to define your service via WSDL which comes with a lot of overhead. REST uses JSON that is much simpler to process and parse. 
• REST doesn’t need a service definition to provide you with a web service

Top 7 SOAP API Vulnerabilities

We have now covered the basics. Now let’s talk about the 7 most common vulnerabilities and how to prevent them. 

The most common SOAP API vulnerabilities include:

• SOAP Injections
  • SQL Injection
  • XML Injection
  • XAML Injection
  • Command Injection
• SOAP Action Spoofing
• SAML Vulnerabilities
• Replay Attacks
• Cross-Site Scripting
• Broken Access and Authorization
• Denial of Service (DoS)

SOAP Injections

SQL Injection

SQL injection is a web security vulnerability that could allow an attacker to tamper with database queries made by an application, injecting malicious code into queries. In the context of SOAP APIs, this involves injecting malicious SQL queries into API calls that use SQL syntax as part of their inputs. If your API is vulnerable to SQL injection, attackers can change the content or behavior of an application and in some cases compromise the entire server. 

XML Injection (XXE)

An XML or SOAP injection vulnerability occurs when user input is insecurely injected into a server-side XML document or SOAP message. Attackers can use XML metacharacters to change the structure of the generated XML. Depending on the XML capabilities enabled on the server side, it can interfere with your application’s logic, perform malicious actions and allow attackers to access sensitive data.

Command Injection

Command injection is an attack designed to execute arbitrary commands on the host operating system through a vulnerable application. In the context of SOAP APIs, any API that accepts user inputs and performs operating system commands, such as creating directories or accessing files in the file system, can be vulnerable to command injection.

A command injection attack can occur when an application passes insecure user-supplied data (forms, cookies, HTTP headers, etc.) to the SOAP API, which then passes the data to the system shell. In this type of attack, commands injected by the attacker are typically executed with the privileges of the server side of the SOAP API.

XAML Injections

XAML Injection attacks are made possible when untrusted input is involved. XAML is the markup language that’s used to directly represent object execution and instantiation. What does that entail? Any elements made in XAML are able to interact with system resources. What happens when a hacker gains control of the XamlReader method call input? They can execute malicious code. 

To protect against XAML injection, Microsoft enforces a rule in their IDEs, but this rule is not foolproof and can be disabled. The best prevention practice against this is manually validating and sanitizing the received input (learn more below).

SOAP Action Spoofing

Every HTTP request contains a field called a SOAP action, that is used to perform an action defined on the content. If communication is not encrypted, an attacker can place themselves between the client and the server, and perform a variety of bypass or man-in-the-middle (MitM) attacks that can modify the content of SOAP requests or responses.

SAML Vulnerabilities

Security Assertion Markup Language (SAML) originated way back in 2001. It is an XML-based open standard that provides authorization and authentication services. It lets identity providers pass authorization credentials to a service provider (for example, Salesforce SAML SSO). SAML is a common way to implement single sign on (SSO).

How is SAML vulnerable? Hackers found a way to modify SAML body content, but without invalidating the cryptographic signature. That’s the trick, you bypass the main authentication for any affected SAML service provider. A hacker that obtains access to one or compromises another account can then add comments to any attribute, obtaining an administrator account, for example.

Replay Attacks

The biggest problem with APIs is that they’re open to the public. In the sea of incoming requests, you need to know which are safe and which aren’t. Any web service that’s exposed over an HTTP request is vulnerable to attacks, such as a replay attack. 

What can a hacker do when he acquires the web service request together with valid input parameters? Attack manually over and over again or use automated techniques that repeatedly perform attacks. What kind of damage can these attacks cause? The server’s memory gets consumed. This tanks the server’s performance greatly. 

This attack is even more dangerous when used in conjunction with a malicious code injection in the input parameter. This gives the hacker sensitive data in the response. 

Cross-Site Scripting

Cross-site scripting (also known as XSS) is a web security vulnerability that could allow an attacker to compromise the interaction between a user and a vulnerable API. This allows attackers to bypass same-origin policies that seek to isolate scripts running on different websites from each other. 

Cross-site scripting vulnerabilities typically allow an attacker to impersonate a victim user, perform any actions the user is capable of, and gain access to user data. In the context of a SOAP API, a successful XSS attack would allow the attacker to perform user actions that result in API calls that are processed with the same privileges of the legitimate user.

Broken Access and Authorization

Access control enforces policies to prevent users from operating beyond their expected privileges. Common access control vulnerabilities in SOAP APIs include:

• Ability to modify URLs, internal application state or HTML pages, to bypass access control checks.
• Ability to change a primary key to another user’s record, allowing an attacker to view or edit another user’s account.
• Ability to escalate privileges, such as logging in as a regular user and receiving administrative privileges. 
• Ability to manipulate or tamper with JSON Web Token (JWT) metadata, cookies, or hidden fields that affect user authorization.
• Incorrect Cross Origin Resource Sharing (CORS) configuration allowing unauthorized API access.
• Ability to access authenticated content or operations as unauthenticated users, or force retrieval of privileged content or administrative operations as a standard user. 
• Ability to access APIs without sufficient control for POST, PUT and DELETE operations.

Denial of Service (DoS)

Denial of service (DoS) attacks on APIs flood the API endpoint with traffic, in order to disrupt service and deny access to legitimate users. DoS attacks can significantly degrade the quality of service experienced by legitimate users of the API, cause significant delays in response, and eventually result in downtime.

DoS attacks are not limited to disruption of service. An attacker could inject and execute arbitrary code into an API during a DoS attack, to access sensitive information or execute commands on the server. 

SOAP Security Best Practices: Preventing SOAP Security Threats

What actions help protect SOAP APIs? Continue reading to find out!

Input Validation

Input parameters are the entry points that are exploited when a hacker wants to access layers of an application. Hackers can inject their malicious code into an API message. This malicious code then endangers your entire application.

Regex Protection is a good security technique. XML or JSON payload, URL Path, Header. These incoming requests need to be evaluated against regular expressions like EXECUTE, DELETE, and UPDATE. Rejecting any detected request that’s vulnerable is important.

Input HTTP Verb Validation deals with HTTP verbs/methods. These include DELETE, GET, POST, PUT, PATCH, HEAD, TRACE, and OPTIONS. All of them need restrictions. The approved verbs are allowed to function while the rest of the methods should only return a valid response code.

Then there’s Headers Validation. Many kinds of Security Headers exist. Content-Length, Accept, Content-Type. All of them need validation against API. It’s also important to always perform validation for obligatory headers. API-specific headers and Authorization for example. In the case of custom-defined headers, we need to make sure to validate proper formatting and value (X-Access-Token).

Validating incoming content-types is also important. How do you validate the Content-Type policy for PUT/POST/DELETE requests? IBy ensuring  the values for the request and the Content-Type header are the same. If the API detects that value does not match type, it returns a Bad Request Response (400).

Lastly, you need to handle Unsupported Resources. Addressing this is easy, by only permitting allowed resources and blocking unknown resources.

Access Control

All APIs need special configuration. Why? So that only approved IP domains or regions are allowed. Any requests that don’t meet the set conditions should get rejected.

There are many different approaches to managing resource access. The most common method is role-based access control. By default users have all permissions denied to ensure full level security. Afterwards administrators grant required privileges to appropriate roles. Several types of permission levels exist. They include:

• Never (Regardless of role, this function restricts the user completely, making them unable to perform any operation)
• Always (This access level allows the user to perform operations as they see fit no matter what role they have)
• Grant (A user can perform an operation unless an entity-level permission disallowed it)
• Entity (Users that obtained access via entity-level permissions can perform the operation)

Implement Authentication for SOAP APIs

Each security layer in the organization requires comprehensive authentication. Without it, the API is vulnerable, making the data vulnerable as well. For example, hackers that have a valid mobile number are able to steal sensitive data. That’s why we use OAuth/OpenID. They offer complex and potent authentication and authorization mechanisms. It’s recommended to authenticate the end-user and the application as well. 

Usage of 2FA, OAuth, and Nonce tokens improve access control and can also help prevent replay attacks. A Nonce token combines a unique GUID and a timestamp. One token is valid for one request. That way any request is unique, making it free of vulnerabilities. Use signed URLs for providing access to media type resources.

Enable SAML Authentication

If you use SAML for SSO, it is essential to use SAML authentication. The SAML authentication model has two parts:

• An identity provider  – produces all SAML assertions
• A service provider (SP) – a consumer of assertions. This could be, for example, G Suite, Office 365, or other SAML-supported cloud applications.

Most SAML assertions are signed with a PKI signature. This signature checks if the assertion is valid or not.

Any cloud application that’s being accessed needs an authentication service – one that acts as an identity provider (IdP) – to collect user credentials and return a response to the accessed cloud application. This response is what we call a SAML assertion. This assertion can contain a reject or accept response only. The user successfully logs into the app if the SAML assertion is confirmed to be valid.

Ensure URLs Never Contain API Keys

Any API needs standard authentication and authorization mechanisms. Yet there are cases where the API key gets sent as a part of URI (Uniform Resource identifier). This makes the key compromised as it’s shown as a plain text in your browser. Sending API keys via the GET method is also a problem. Why? Because they can be stored either in the system logs as cache or in the browser history. This makes them accessible to other users. You never want your API  key to be part of URI and should prefer sending it as part of headers instead of sending it via GET.

Automating SOAP Security with Bright

In summary, SOAP APIs have many advantages. It’s a more secure protocol than REST, it supports automation, and it’s standardized to an incredible degree. Yet, the inherent use of SOAP APIs also brings more overhead to SecOps teams. We’ve listed common vulnerabilities and what you can do to prevent them. However, you can automatically apply SOAP security best practices with an automated security testing solution.

Most legacy Dynamic Application Security Testing (DAST) tools support API security testing. Those that have attempted to make the leap are unable to support SOAP API security testing, resulting in a continued reliance on expensive manual testing, carried out late in the process and often after the API is in production.

With Bright, you can test your SOAP, REST and indeed GraphQL APIs, either as a standalone scanner or integrated seamlessly across your DevOps and CI/CD pipelines. You can now start to detect, prioritise and fix issues early, before they hit production.

By simply uploading the OpenAPI (Swagger) or Postman collections into Bright, you can achieve a comprehensive security scan that will cover the OWASP API Top 10 vulnerabilities. This can be achieved for a full scan against the complate target or for scope defined incremental testing on each new build, feature or merge.

Additionally, Bright has unparalleled support for a range of different authentication mechanisms, including SAML, OIDC, OAuth and more, ensuring you have maximum coverage.

API security testing tools are now a thing of the present and no longer needs to be an afterthought and another human bottleneck in your processes – start automating your security testing.

Get a free account for Bright and start testing today!

A CSRF (Cross-Site Request Forgery) token is a unique security measure designed to protect web applications from unauthorized or malicious requests. It’s a specific type of token, often referred to as a synchronizer token or challenge token, that verifies the authenticity of requests made by a user. Each CSRF token is unique to an individual user session and is embedded in web forms or requests. When a user submits a form, the server checks the CSRF token to ensure it matches the one it issued, confirming the request’s legitimacy. This token is crucial for security, as it prevents attackers from performing actions on behalf of unsuspecting users. To maximize security, a CSRF token should be a large, unpredictable value, making it extremely difficult for attackers to guess or replicate

In this article you are going to learn:

• What is a CSRF token?
• How should CSRF tokens be generated?
• How should CSRF tokens be transmitted?
• How to fix the CSRF vulnerability in popular web frameworks?
• How Bright can help with CSRF Token security

What is a CSRF token?

A CSRF Token is a secret, unique and unpredictable value a server-side application generates in order to protect CSRF vulnerable resources. 

The tokens are generated and submitted by the server-side application in a subsequent HTTP request made by the client.

After the request is made, the server side application compares the two tokens found in the user session and in the request. If the token is missing or does not match the value within the user session, the request is rejected, the user session terminated and the event logged as a potential CSRF attack.

How should CSRF tokens be generated?

Just like session tokens in general, CSRF tokens should contain significant entropy and be strongly unpredictable.

You can achieve this by using a cryptographic strength pseudo-random number generator (PRNG), seeded with the timestamp when it was created and a static secret.

For further security, you can generate individual tokens by chaining their outputs with user-specific entropy and take a strong hash of the whole structure.

This presents an additional obstacle to a malicious user who attempts to analyze the tokens based on a sample that is issued to him.

In short, here are the principles you should follow when generating and verifying your token:

• Use a well-established random number generator with enough entropy
• Make sure tokens can’t be reused. Expire them after a short amount of time
• Verify the received token is the same as the set token in a safe way, for example, compare hashes
• Do not send CSRF tokens in HTTP GET requests. This will make sure they are not directly available in the URL and they don’t leak in the Referer header with other referrer information

For example, a CSRF token in PHP can be generated as follows:

$_SESSION[‘token’] = bin2hex(random_bytes(24));

And verify the token as follows:

if (hash_equals($_SESSION[‘token’], $_POST[‘token’])) {
// Action if the token is valid
} else {
// Action if the token is invalid
}

If you prefer a more secure approach, generate separate tokens for each form. Make sure you don’t expose the token directly to the user’s browser. Hash the token using the filename of the form Hash the token with the filename of the form. Here is one example how to do it in PHP:

hash_hmac(‘sha256’, ‘post.php’, $_SESSION[‘internal_token’])

When you verify, compare the hashes. If both the token and the form are valid, the hashes will match.

How should CSRF tokens be transmitted?

CSRF tokens are secrets and should be handled as such in a secure manner throughout their lifecycle.

Try transmitting the token to the client within a hidden HTML form field, using the POST method. This way the token will be included as a request parameter when the form is submitted.

Place the field containing the CSRF token as early as possible within the HTML file. Place the field that contains the token before any non-hidden fields and before any places where user-controllable data is embedded. This way you will mitigate the risk against various techniquest where an attacker can use crafted data to manipulate the HTML document and capture part of its content.

For example:

You can place the CSRF token into the URL query string, but this approach is less safe, as the query string:

• Is logged in various locations (client and server-side)
• Can be transmitted to third parties within the HTTP Referer header
• Can be displayed on-screen within the user’s browser

To further defend against an attacker who manages to predict or capture another user’s token, insert the CSRF token in the custom HTTP request header via JavaScript. This approach is particularly well suited for AJAX or API endpoints. Browsers usually don’t allow custom headers to be sent cross-domain. The downside of this approach is the limitation for the application to make CSRF-protected requests using XHR, and might be considered over-complicated for many situations.

Never transmit CSRF tokens within cookies.

How to fix the CSRF vulnerability in popular web frameworks?

CSRF protection in Angular

Angular is a popular frontend framework developed by Google. It’s an open-source project and offers its own set of user interface components that work across devices and platforms.

Angular packs the common security measure of reading the CSRF token called “CSRF-TOKEN”, and sets a custom header named “X-XSRF-TOKEN”. However, Angular is just a client-side framework, so to protect against CSRF, your web server must support this protective method as well.

CSRF protection in Django

Django is a free backend framework based on Python. Django focuses on reusability of code and pluggability of modules along with low coupling and rapid development principles.

Django offers middleware for protecting a web server against CSRF attacks. To protect your apps, the middleware must be activated in your project. Also, you have to include the csrf_token tag inside the form elements which point to any in-project URLs.

CSRF protection in Express

Express is a backend web framework for Node.js. It is fast, flexible and minimalistic. It’s free and open source.

Since Express is a minimalistic web framework, it doesn’t support any anti-CSRF measures by default. But it provides a pluggable middleware that helps your web server to protect itself against CSRF attacks.

The middleware is known as “csurf”, and it’s super easy to set up in your project. It offers some bootstrap options as well to configure its functionality.

CSRF protection in Laravel

Laravel is a free, open source web framework for PHP. Laravel supports a modular packaging system and offers numerous utilities to ease the development and maintenance of web applications.

Part of Laravel’s middleware group is middleware named VerifyCsrfToken. VerifyCsrfToken auto-verifies the token in incoming web requests and disregards CSRF-based requests. To use it, just include @csrf in your forms to include the token field.

CSRF protection in React

React is a front-end framework developed by Facebook. It’s free and open source and is mostly used for building mobile or single-page applications.

Unlike Angular, React doesn’t come with a default security measure against CSRF attacks. 

In order to protect a React application against CSRF, you have to introduce a security solution in your app, and have the web server support it.

Luckily, it’s easy to implement CSRF protection in React. You only have to store the CSRF token in your React app and generate relevant headers to send along with the request to the server. The server will quarantine all CSRF requests.

Bright’s technology for CSRF Token security

You can easily stop CSRF attacks by just adding code that requires a CSRF token. To do so, you need to know which applications are vulnerable and where, and Bright can help!

Bright automatically scans every aspect of your apps, providing actionable reports. It seamlessly integrates with the tools and workflows developers already use. Scans are fast as our AI-powered engine can understand application architecture and generate sophisticated and targeted attacks. The results are completely false-positive free, so you can focus on releasing code.

Try Bright today, and start testing for CSRF, XSS, and hundreds of other vulnerabilities in minutes – https://app.brightsec.com/login

Want to learn more about CSRF?

Have a look at these articles:

• CSRF Attacks: Real Life Attacks and Code Walkthrough
• What is a Cross-site Request Forgery (CSRF) attack?
• CSRF vs XSS: What do they have in common and what is the difference

Microservices have become the leading method of application development.

Unfortunately, security testing has not evolved quickly enough to address the risks introduced by this mass adoption of microservices. 

Engineers and architects are challenged by security issues that arise with microservices. If these concerns are not addressed in the SDLC, vulnerabilities will appear in production. 

The common practice is to test for vulnerabilities in each microservice, the reason is that every instance of microservice exposes its own set of entry points, APIs, and communication paths that create exposure to additional attack vectors that are currently not addressed. But this is not so simple to achieve in a complex microservices architecture.

This is part of a series of articles about Web Application Security.

In this article, you will learn:

• The Top 5 Challenges of Microservices Security
  • Infrastructure Design and Multi-cloud Deployments
  • Segmentation and Isolation
  • Identity Management and Access Control
  • Data Management
  • The Rapid Rate of Application Changes
• Best Practices for an Effective a Microservices Security Architecture
  • Deploy Security at Container Level
  • Create an API Gateway
  • Isolation
  • Use OpenID or OAuth 2.0
  • Don’t Show Sensitive Data As Plain Text
• Automated Microservices Security with Bright

Top 5 Microservices Security Challenges

The diagram below illustrates how even a simple microservices architecture involves multiple components, each with its own vulnerabilities and security risks. Let’s review the top 5 microservices challenges making it difficult to secure modern applications.

1. Infrastructure design and multi-cloud deployments

Microservices are distributed over many data centers, cloud providers, and host machines. 

Building infrastructure across many cloud environments increases the risk of losing control and visibility of the application components.

2. Segmentation and isolation

Decoupled application components perform their duty in co-dependence with many other services. 

All these components establish and maintain communication channels over different infrastructure layers, so often cross-service communication is skipped when testing for security vulnerabilities, the result of this is significant exposure in the interfaces between these services.

3. Identity management and access control

Microservices expose new entry points to both internal and external actors.

Access controls need to be regulated for all entities, whether legitimate or illegitimate.

It’s important to have an administrative interface that can help you manage users, applications, groups, devices, and APIs from one central location, giving you real-time visibility into what’s happening in your environment.

4. Data management

Data generated in a microservices architecture moves, changes, and is continuously interacted with. Data is also stored in different places and for different purposes. Owners of data assets need insight into the life cycle and the dynamics of data to avoid breaches.

Can you be sure that your data is secure?

Data leaks can happen regardless of the communication channel’s exposure. Malicious actors can chain vulnerabilities to break through to private assets.

5. The rapid rate of application changes

Application development in modern SDLC forces the code base and data stores to grow over time. Development methodologies push iterative and incremental development, putting microservices under the constant workload.

How can you know at any time that new code coming through the development pipeline will not expose your application to the new sets of vulnerabilities and dangerous attack vectors?

Security testing must keep up with the pace of the SDLC, to enhance DevSecOps.

Decomposing applications into microservices increases the application’s attack surface because of newly added entry points and connections between instances that are now spread out over many environments, because of that microservices security requires non-trivial and ready-made solutions.

Related content: Read our guide to websocket security.

Best Practices for an Effective a Microservices Security Architecture

The following best practices can help you design security into your microservices applications and address application security challenges.

Deploy Security at Container Level

In many, microservices are based on container technology. The most glaring vulnerability of containers is that they are based on images, which may contain vulnerabilities. Perform regular scanning to ensure you don’t use images that contain security vulnerabilities or other security issues.

In addition, a container has both internal and external threat surfaces. A great first step to protecting containers at runtimer is adopting the principle of least privilege (POLP). This can involve some or all of the following strategies:

• Limit permissions to the minimum required by each user or service role
• Never use sudo or a privileged accounts to run services
• Limit or control the use and control of available resources—for example, restrict a container’s access to the host operating system
• Never keep secrets on the container, because anyone with access to the container can see them
• Define isolation with appropriate rules for resources with different levels of sensitivity

Create an API Gateway

Microservices often span several different networks, using a variety of technologies, interfaces and protocols. An important way to secure microservices is to create one entry point, which all clients and systems access, and which can easily be secured.

This entry point is called an API gateway. If you design your system in such a way that all clients always connect to the API gateway, you can use it to perform authentication and authorization, and filter requests to sensitive resources. The API gateway authenticates users and service roles and decides which microservices they are allowed to access.

API gateways can provide additional security capabilities like SSL termination, protocol conversion, monitoring, routing, and caching of requests. 

Isolation

In a microservices architecture, each service is a separate, isolated part of the application. You should be able to implement, maintain, modify, extend and update microservices without 

affecting other nearby microservices.

Isolation should also be performed at other layers of the infrastructure, such as the database. One microservice should not have access to data belonging to other microservices. By achieving complete isolation at all layers, attackers who compromise one microservice cannot perform lateral movement to attack other parts of the system.

Use OpenID or OAuth 2.0

OpenID and OAuth 2.0 are two authentication systems that can generate tokens to enable secure user access. Using a system like OAuth 2.0 is excellent for microservices security. It ensures users obtain permissions to any resource via a resource server. 

OAuth can provide four types of authentication tokens—resource server, resource owner, authorization server, and client. Tokens can be used to access resources until they expire. OAuth also provides a mechanism for refreshing tokens after the original one expires. 

Learn more in our detailed guide to web application scanning.

Don’t Show Sensitive Data As Plain Text

Plaintext can be easily read and copied by users and machines. A first step to protecting personally identifiable information (PII) is to avoid displaying it in clear text. All passwords 

and usernames must be stripped or masked when saving logs or records.

Adding TLS/HTTPS will not solve the problem, if data is stored unsecurely at rest. You can also try to encrypt logs, but this won’t help against attackers who can directly access system memory. Therefore the only safe route is to avoid persisting sensitive information in the first place.

Automated Microservices Security with Bright

Bright integrates automated AI-powered Dynamic Application Security Testing into the SDLC to scan applications built atop of the complex microservices architecture each time the application code is packaged to a running application and forwarded to the testing phase.

Bright provides you with real-time reports with zero false positives in no time, where you can see reported vulnerabilities with a reproducible proof-of-concept and ranked by the severity of the impact they make on an application, this confirms the overall health and capacity of an application to handle production runtime without being exposed to vulnerabilities, regardless of the scope and the complexity of the underlying microservices architecture mesh. 

Start protecting microservices today — try Bright free

Table of Contents

1. Example: Combining Checkmarx SAST & SCA and Bright’s DAST
2. Engineering Security Testing Metrics

DevOps looks to combine the culture, methodologies and tooling of both the software development and operations teams, so companies can deliver new application features at a much greater velocity. 

DevSecOps takes this a step further, integrating security into DevOps, shifting security testing left. Instead of developers being brought into the fold later in the process, developer focused security testing tools bridge the gap between engineering and security.

One of the key challenges when implementing DevSecOps is prioritizing which vulnerabilities need to be remediated first. This is especially true when using multiple Application & API security testing tools to provide full coverage.

Automation is key. Implementing application security testing into the CI/CD pipeline to detect and fix security vulnerabilities on each build, or every merge to master, delivers secure and compliant application changes rapidly, while running operations consistently with the automation.

It’s not a one size fits all, with different types of automated security testing tools required across the pipeline to ship secure applications and APIs, at speed. 

Identifying security vulnerabilities at various stages of the pipeline requires the integration of several tools. These include SCA (Software Composition Analysis), SAST (Static Application Security Testing) and DAST (Dynamic Application Security Testing).

We previously discussed combining DAST with SCA from Checkmarx. 

Leveraging these tools is great, but aggregating the vulnerability findings can be a challenge. A ‘single pane of glass’ is often needed so that the engineering and security teams have the visibility they need. Indeed, combining SCA+SAST+DAST information can be very valuable for SIEM (Security Incident Event Management) correlation engines for example, where the vulnerability information can help in providing more accurate correlation and attack detection.

Example: Combining Checkmarx SAST & SCA and Bright’s DAST

Bright’s partner, Datastream, has integrated the Checkmarx SAST and SCA solutions and Bright’s DAST platform Bright, within their proprietary xDashy platform, where their clients across the financial, retail and e-commerce sectors are benefitting from this comprehensive testing and aggregated data.

Combining security testing on the code level (SAST), checking dependencies (SCA) whilst also being able to test the runtime application (DAST), delivers comprehensive security testing integrated across DevOps / CICD pipelines at multiple stages, into the hands of developers.

Our joint customers’ engineering and security teams get full visibility and can manage custom dashboards, define executive reports, metrics and KPIs that improve decision-making at both the executive and technical level, consolidating SAST, SCA and DAST results on a single screen. 

For example, SCA will identify security vulnerabilities in 3rd party dependencies, building the open source dependency trees for applications and mapping these against a database of known vulnerabilities. It then reports vulnerable open source that has been pulled into the application, to fix or patch accordingly.

Bright engine tests for vulnerabilities that come under the OWASP Top 10 and Mitre, leveraging thousands of payloads, to test both webapps and APIs. 

Bright is also the only DAST solution on the market that can scan for specific Business Logic Vulnerabilities, normally carried out by manual testing. 

Having these tests automated, as part of your development pipelines and included in your dashboard gives you the broadest picture of your cyber posture. Coupled with Bright’s automatic validation of every security finding, the DAST output delivers real time actionable results, with no false positives. 

If you are considering a DAST tool, be sure to read our blog on the Must-Have features of your DAST Tool.

Security teams can then understand the risk, prioritise remediation and coordinate with the engineering team accordingly.

Additionally, by combining the tools and aggregating the results, companies can establish a common risk identification framework through linking projects manually and by referencing vulnerabilities according to the CWE (Common Weakness Enumeration), Miter’s CVE and also categorized by the CVSS v3 score provided by Bright.

Engineering Security Testing Metrics

Being able to visualise and correlate data across projects, squads or teams is also invaluable. 

Bright has a comprehensive ‘Projects’ reporting functionality which can be used via the Bright app UI, or integrated with your SIEM or other reporting platform, as Datastream has integrated with their platform, xDashy. Users can filter the results by project, by execution date and compare the results over time, graphically presenting trends and showing a visualization of risk management. 

Having visibility of the most frequently recurring risks, or being able to drill down into which team or project is generating certain vulnerabilities, allows you to prioritise remediation as well as providing targeted training on secure coding.

This helps with capacity building for secure development as well as providing for analysis of the cost and time to remediate.

Whether you are looking at enhancing your current SAST and / or SCA scanning or just entering into the realm of security testing, using Bright’s DAST is really simple and can be used as a standalone scanner by the security team or integrated across your pipelines.

Whether testing your webapps or APIs (SOAP, REST, GraphQL), the results produced are organised in a developer friendly way and as a QA, can help establish a culture of security testing and let you champion security testing!

Go ahead and try it out! With our free account, you can get started today; get your account now – https://app.brightsec.com/signup

Table of Contents

1. How does developer-focused DAST augment  SCA and make you more secure?
2. Get started today.

The shift to rapid, frequent deployments over the past decade left application security behind. However, in recent years security is starting to catch up. Leading companies are now integrating security testing into CI & CD, running automated tests with every commit, and fixing bugs long before they hit production.

Software Composition Analysis (SCA) and developer-centric DAST enable this and are easily achieved by combining Checkmarx and Bright.  Different types of automated security testing tools are required across your pipeline to produce APIs and applications that are secure by design. Don’t stop with securing 3rd party code, make sure you secure 1st party code as well.

How does developer-focused DAST augment  SCA and make you more secure?

Software Composition Analysis (SCA) 

SCA is a set of technologies that analyze the application’s open-source components tied together. 

As the analyzed code is transparent and available to the tool, SCA offers accuracy when it comes to recognizing flaws in the code by detecting the exact line of code that needs remediation reducing the remediation time and effort for developers.

For organizations using open-source, SCA like Checkmarx should definitely be used to achieve some level of security, but is it enough?

Dynamic Application Security Testing  (DAST)

Although SCA can detect many vulnerabilities, everything they identify is in open-source components third-party libraries and do not cover 1st party code that you develop within your organization. 1st party code represents more than 60% of code for most organizations.

Being a black-box solution, DAST interacts with the app from the outside. DAST tests the application’s and API’s defense against techniques that a hacker might use while trying to exploit your application. Because of DAST’s language independence, you won’t have problems integrating a DAST tool into a CI/CD pipeline. 

So, which technology should you focus on and why?

Checkmarx SCA & Bright DAST – Complete Developer-Centric AppSec Testing

To be secure by design and ensure you are shipping secure applications and APIs to production, SCA like Checkmarx and Bright’s automated DAST should be used to complement each other. If you combine these two powerful and modern tools you can detect even 0-day vulnerabilities.

Checkmarx’s SCA gets you visibility of your open source vulnerabilities that may underpin your applications.

Bright enhances DevSecOps at its core, with a Dev First approach to test your applications and APIs (SOAP, REST, GraphQL). Test every build and get results you can trust, with automatically validated results free from false positives and developer-friendly remediation guidelines.

Get started today

New to Bright and/or Checkmarx? Try us both for free to start testing for vulnerabilities in your applications today

Sign up for a FREE Bright account here – follow our quick step wizard and be up and scanning in minutes!

To get started with Checkmarx request a demo here!

You can learn more about Bright, all our integrations, and more on our knowledge base.

Table of Contents

1. How does developer focused DAST augment SCA?
2. Get started today.

As security testing is increasingly shifting left, developer focused application security testing tools are bridging the gap between engineering and security.

But automated tools are not a one size fits all, with different types of automated security testing tools required across your pipeline to ship secure applications and APIs, at speed.

Software Composition Analysis (SCA) and developer-focused DAST enable this and it is easily achievable with FOSSA and Bright, respectively.

How does developer focused DAST augment SCA?

Software Composition Analysis (SCA) 

SCA identifies security vulnerabilities in your 3rd party dependencies, by building the open source dependency trees for your applications and mapping 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.

The use of open source has grown dramatically over the past few years, with flaws in open source dependencies being more prevalent than ever.

For any organization using open source, SCA like FOSSA’s should definitely be used to achieve a degree of security, but is that enough? 

Dynamic Application Security Testing (DAST)

Developers are usually not familiar with DAST, which is not surprising. Historically DAST solutions were built for security teams, and run either by the internal security team or outsourced testing companies on production applications.

But DevSecOps forces those tests to be conducted much earlier in the development process.

Bright’s innovative developer-focussed DAST enables developers to detect and fix security bugs that they have introduced (the custom or 1st party code). This is done as part of the developer’s workflow or as part of their CI/CD pipeline.

With Bright, an automated DAST scan can be triggered on every build / commit or PR, to test your runtime applications and underlying APIs (whether REST, SOAP, or GraphQL), detecting vulnerabilities like SQL Injection and Cross-Site Scripting (XSS), for example.

Scans that last minutes and not hours keep up with your rapid release cycles and are not a bottleneck, maintaining DevOps speed.

Having that direct feedback loop to developers means you can fix early and often. Bright’s plug and play integrations with your pipeline are seamless – developers can stay in their environment with Bright’s CLI, as well as integrating with the likes of CircleCI, Jenkins, JFrog, AzureDevOps, JIRA and more.

While false positives are notoriously an issue with DAST tools, Bright’s innovative engine automatically validates every finding…no need for manual validation checks, no delays, and no builds failing for no reason! 

New and recurring issues are identified and flagged as such, so focus and prioritization of remediation is facilitated.

These features mean that there is less of a reliance on manual testing and enables security testing to be placed in the hands of developers.

So, which technology should you focus on and why?

FOSSA & Bright – Complete Developer-Centric AppSec Testing

To ensure your are shipping secure applications and APIs to production, SCA like FOSSA’s, and Bright’s automated DAST should be used in conjunction.

FOSSA’s SCA gets you visibility of your open source vulnerabilities that may underpin your applications, that the creative features are built on top of.

Bright’s innovative DAST lets you very easily detect security vulnerabilities across your applications and APIs. Test every build and get results you can trust, as we automatically validate results free from false positives.

By deploying and leveraging both FOSSA’s SCA and Bright’s DAST, you are covering all your bases. This will enable you to find and fix a broader range of vulnerabilities faster and earlier.

The question is not whether you should be using SCA or DAST, but how and when you can start to use them together across your pipelines. Small hint – see the answer below!

Get started today

New to Bright and/or FOSSA? Try us both for free to start testing for vulnerabilities in your applications today.

Sign up for a FREE Bright account here – follow our quick step wizard and be up and scanning in minutes!

Try out FOSSA for free here too!

You can learn more about Bright, all our integrations and more on our knowledge base

Table of Contents

1. Integrating early into the SDLC
2. Low number of False-positives.
3. Simple usage
4. Application security testing with Bright

Let’s face it – whether you are checking your emails, banking online , shopping for new shoes, or doing serious business, there is a very good chance you are doing it through your web browser. Organizations use the convenience web applications bring to get in front of you, but this convenience does not come without a risk.

As more businesses shift to web apps, they are becoming more attractive targets for cyber criminals. So, what can you do to stay one step ahead of bad actors? – Automate. 

In this article we introduce three key features you have to look for when shopping for your AppSec & API testing automation tool:

Integrating early into the SDLC

Development teams have been using automation to streamline manual activities such as build, deployment and functional testing for years now, and it is time security testing joins the mix. 

By integrating automated security validation into the continuous integration/continuous development (CI/CD) pipeline, you can catch vulnerabilities sooner, reducing the potential risk and financial impact.

According to the NIST (the National Institute of Standards and Technologies), the cost of fixing a security defect once it’s made it to production can be up to 60 times more expensive than during the development cycle.

Additionally, the time it takes to fix a security issue once it is discovered has increased. According to Veracode’s “State of Software Security” report the average amount of time to fix a software defect has gone from 59 days ten years ago, to 171 days. Instead of being remediated during the development cycle, the vulnerability would be in production for almost half a year.

Although SAST tools traditionally did a better job at integrating early into the SDLC,  modern DAST tools are catching up and can be integrated as early as the build phase.

Low number of False-positives

We all know the story about the boy who cried wolf.

The tale tells the story of a shepherd boy who repeatedly tricks nearby villagers into thinking a wolf is attacking his town’s flock. When a wolf actually does appear and the boy again calls for help, the villagers believe that it is another false alarm and the sheep are eaten by the wolf.

What if the same happens with application security? With all the false positives and false alarms, you could skip a serious, real vulnerability that could be exploited. Moreover, even if you don’t miss anything, you end up spending hundreds of hours trying to figure out what is real.

It’s crucial you find a tool that returns as few false positives as possible. We at Bright make sure to automatically validate every finding before reporting it to you. That way we ensure you spend the time and resources into remediating real, exploitable vulnerabilities.

Simple usage

One of the problems automation solves is the huge global shortage of security professionals. Having a tool that requires a team of security professionals to work with shouldn’t be mandatory. To see the real benefits of automation, you need a tool that your existing teams will love and know how to use.

Not even the best AppSec Testing tool is useful if your team is not going to use it.

That’s why we at Bright built our tool from the ground up with developers in mind. We made sure developers don’t have to leave the environment they already use and can configure and start a scan with code, but we also made sure our UX is simple enough so that other teams, like QA, will enjoy using it.

Application security testing with Bright

Bright enhances DevSecOps at its core, with a Dev First approach to test your WebApps and APIs

Key features of our technology include:

• Shallow learning curve: to establish a culture of security testing across your pipelines
• Built for Developers: We empower developers to detect and fix vulnerabilities on every build, enabling them to leverage multiple discovery methods to initiative a scan, including:
  • Crawling – for full automation
  • HAR files – generated per build/commit for scope defined testing or by QA Automation
  • OpenAPI (Swagger) files or Postman Collections – to test APIs or Single Page Applications
• Smart Scanning functionality: leveraging sophisticated algorithms to carry out the right tests against the target, removing complexity for developers whilst ensuring scans are automatically optimized to maximize speed and prevent development drag
• Built for Modern Technologies: Microservices, Single Page Applications, APIs (REST, GraphQL) are all supported 
• No False Positives: The only tool with fully automated validation of every vulnerability detected, freeing up valuable time for your security team and saving a considerable amount of money, to release fast and be secure by design
• Seamless Integration: Rest API, CLI for developers, or with common tools such as CircleCI, Jenkins, Jira, GitLab, Github, AzureDevOps and more

Table of Contents

1. How does developer focused DAST augment  SCA and make you more secure?
2. Get started today.

Security is no longer a siloed team with sole ownership of security testing – security testing is increasingly shifting left. Instead of developers being brought into the fold later in the process, developer focused security testing tools are bridging the gap between engineering and security.

Automation is key, with those implementing application security testing into their CI/CD pipeline to detect and fix security vulnerabilities on each build or every merge to master, seeing a considerable benefit. 

It’s not a one size fits all, with different types of automated security testing tools required across your pipeline to ship secure applications and APIs, at speed. 

Software Composition Analysis (SCA) and developer-centric DAST enable this and is easily achievable with Snyk and Bright, respectively.

How does developer focused DAST augment  SCA and make you more secure?

Software Composition Analysis (SCA) 

SCA is a widely used form of developer application security testing, with Snyk being amongst the leaders in the field. SCA identifies security vulnerabilities in your 3rd party dependencies, by building the open source dependency trees for your applications and mapping 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.

The use of open source has grown dramatically over the past few years, with flaws in open source dependencies being more prevalent than ever.

For any organisation using open source, SCA like Snyk’s should definitely be used to achieve a degree of security, but is this enough? 

Dynamic Application Security Testing  (DAST)

Not all developers are familiar with DAST, which is not surprising. Historically DAST solutions were  built for security teams, not developers, and run either by the internal security team or outsourced testing firms on production applications. 

With DevSecOps, these tests need to be conducted much earlier in the development process to get a feedback loop to the developers.

While SCA looks at your source code and dependencies, Bright’s innovative developer-focussed DAST enables developers to detect and fix security bugs that they have introduced – the custom (or 1st party) code. This is done as part of the developer’s workflow or as part of their CI/CD pipeline. 

With Bright, an automated DAST scan can be triggered on every build / commit or PR, to test your runtime applications and underlying APIs (whether REST, SOAP, or GraphQL), detecting vulnerabilities like SQL Injection and Cross-Site Scripting (XSS), for example.

Scans that last minutes and not hours keep up with your rapid release cycles and are not a bottleneck, maintaining DevOps speed.

Having that direct feedback loop to developers means you can fix early and often. Bright’s plug and play integrations with your pipeline are seamless – developers can stay in their environment with Bright’s CLI, as well as integrating with the likes of CircleCI, Jenkins, JFrog, AzureDevOps, JIRA and more.

Whie false positives are notoriously an issue with DAST tools, Bright’s innovative engine automatically validates every finding…no need for manual validation checks, no delays, and no builds failing for no reason! 

New and recurring issues are identified and flagged as such, so focus and prioritisation of remediation is facilitated.

These features mean that there is less of a reliance on manual testing and enables security testing to be placed in the hands of developers.

So…which should you focus on and why?

Snyk & Bright – Holistic Developer-Centric AppSec Testing

To be secure by design and ensure you are shipping secure applications and APIs to production, SCA like Snyk’s, and Bright’s automated DAST should be used in conjunction.

Snyk’s SCA gets you visibility of your open source vulnerabilities that may underpin your applications, that the creative features are built on top of.

Bright’s innovative DAST lets you very easily detect security vulnerabilities across your applications and APIs. Test every build and get results you can trust, with automatically validated results free from false positives and developer friendly remediation advice.

By deploying and leveraging both tools, you are covering all your bases, to find a broader range of vulnerabilities faster and earlier, to fix them…faster and earlier!

The question is not whether you should be using SCA or DAST, but how and when you can start to use them together across your pipelines…the answer is, very easily (see below)!

Get started today

New to Bright and/or Snyk? Try us both for free to start testing for vulnerabilities in your applications today

Sign up for a FREE Bright account here – follow our quick step wizard and be up and scanning in minutes!

Try out Snyk for free here too!

You can learn more about Bright, all our integrations and more on our knowledge base