3 Simple CSRF Examples to Understand CSRF for Good
What is CSRF (Cross Site Request Forgery)?
Cross-site request forgery (CSRF) is a technique that enables attackers to impersonate a legitimate, trusted user. CSRF attacks can be used to change firewall settings, post malicious data to forums, or conduct fraudulent transactions. In many cases, affected users and website owners are unaware that an attack occurred, and become aware of it only after the damage is done and recovery is not possible.
CSRF attacks exploit a mechanism that makes the sign-in process more convenient. Browsers often automatically include credentials in the request when a user tries to access a site. These credentials can include the user’s session cookies, basic authentication credentials, IP address, and Windows domain credentials.
If there is no protection against CSRF attacks, it can be easy for an attacker to hijack the session and impersonate the user. Once a user is authenticated on the site, the site cannot differentiate between a legitimate user request and a fake request sent by the attacker.
Consider a user who wants to transfer an amount of $5,000 to a family member via the web application of Acme Bank, which has a CSRF vulnerability. An attacker identifies this vulnerability and wants to intercept this transaction so that the funds are transferred to their bank account instead of to the intended recipient.
The attacker can construct two types of URLs to perform the illicit funds transfer, depending on whether the application was designed using GET or POST requests.
Forged GET request
The original request would look like something like this, transferring the amount to account #344344:
GET http://acmebank.com/fundtransfer?acct=344344&amount=5000 HTTP/1.1
The attacker’s forged request might look like this. The attacker changes the account number to their own account (#224224 in this example) and increases the transfer amount to $50,000:
Now the attacker needs to trick the victim into visiting this forged URL while signed into the banking application. The attacker might draft an email like this:
To: Victim Subject: A gift of flowers for you!
Hello victim, We know your birthday is coming up and have a special gift for you. Just click here to receive it!
The link “click here” would lead to the forged URL shown above.
Alternatively, the attacker could display a pixel within the email that fires and activates the URL if the victim enables viewing images in their email client. This is more dangerous because it requires no direct user action:
ForgedPOST request
If the banking application uses POST requests, the user’s original operation would look like this:
POST http://acmebank.com/fundtransfer HTTP/1.1 acct=344344&amount=5000
In this case, the attacker would need to craft a
SQL Injection in Python: Example and Prevention
What is SQL Injection?
SQL injection (SQLi) involves adding malicious code to a database query to gain unauthorized access to a web application’s database. Threat actors employ SQL injection techniques to manipulate SQL code, intending to execute malicious code that can help them gain access to sensitive data or compromise the database server.
A successful SQL injection attack can potentially expose any data stored by the database, including intellectual property, administrative credentials, and customer data. Threat actors can use SQL injection to target any SQL database, such as MySQL, SQL Server, and Oracle. Typically, SQL injection attacks target web applications using a database on the back end.
SQL injection is a common security exploit. Threat actors employ this technique frequently, using automated tools to increase the number of attacks they can launch and the scope of the attack. SQL injection is ranked #3 in the OWASP Top 10 lists of web application vulnerabilities.
Threat actors launch SQL injection attacks by first identifying vulnerable user inputs in a web application or page employing user input directly within an SQL query. This vulnerability allows actors to create and send input content (malicious payload) that executes malicious SQL commands in the database.
Web applications and sites typically store all data in SQL databases. SQL is a query language that manages the data stored in a relational database. SQL commands perform actions on data, allowing access, deletion, and modification. It may also allow running operating system commands. As a result, successful SQL injection attacks can lead to critical consequences.
Threat actors launch SQL injection attacks to gain unauthorized access to data and then steal it, modify it, delete it, or perform malicious actions on the breached database. For example, SQL injection can grant access to user credentials, allowing actors to impersonate database users. If the user is a database administrator, the actor gains access to all database privileges.
SQL enables authorized users to choose data and output it from the database. SQL injection vulnerabilities can allow threat actors to gain unauthorized access to all data in the database server. Threat actors can use the privileged obtained through SQL injection to modify data, add new data to the database, delete records, and drop tables.
Example of SQL Injection in Python
The following example shows a SQL injection vulnerability in a Flask application. It is based on code provided by SecureFlag.
The application defines a route for the URL /login and requests credentials from the user:
Next, the application connects to a database running on the localhost:
db = pymysql.connect("localhost") cursor = db.cursor()
This part of the application is vulnerable to SQL injection. The app runs a SQL query in which it insecurely concatenates the username and password fields:
cursor.execute("SELECT * FROM users WHERE username = '%s' AND password = '%s'" % (username, password))
If the query returns a matching record, the application logs the user in:
record = cursor.fetchone()
if record:
session['logged_user'] = username db.close()
Because the application accepts user inputs and processes them with no validation as part of the SQL query, it is possible for the attacker to switch context and override the authentication mechanism.
For example, the attacker could inject the following string into the username field:
john' OR 'a'='a';--
The following query is then submitted to the database:
SELECT * FROM users WHERE username = 'john' OR 'a'='a';-- AND password = '';
Because the ‘a’=’a’ statement is always true, the expression allows the attacker to login with the username john, if it exists, or with the first entry in the user table. The characters ;– comment out the rest of the SQL query, causing the application to ignore the password field.
The most important way to prevent SQL injection is to avoid vulnerable code and insecure coding practices. Here are a few ways to do that—they will be effective against SQL injection and many other vulnerabilities that can affect your Python code.
1. Insecure Packages
When you import a module into a Python application, the interpreter runs the code. This means you should be careful when importing modules.
The PyPi package index is a great resource, but there is no verification that all the code in libraries listed there is secure. Many malicious packages exist on PyPi, some of them attempt to trick users by adopting the names of well known libraries with small misspellings.
If you are unsure of the authenticity and contents of the outer packaging, investigate further, and if you are still unsure about its origin or security status, don’t use it.
2. Identifying Vulnerabilities
The first step in preventing vulnerabilities is to create a checklist of security best practices and review it before releasing your code or promoting it to a test environment. You should adhere to these best practices at the development stage, and automatically verify them at the testing stage. Ideally, you should adopt automated tools that scan your code at all stages of the software development lifecycle (SDLC).
3. Use Linters and Static Analysis Tools
Linters are tools that provide automated recommendations about good coding practices. They are a simple form of static application security testing (SAST) tools, which analyze source code during the development phase of a project. Linters can be used manually in the editor, as part of a local development process, or as part of an automated testing process.
There are several linters in Python, including:
Pylint—Python’s de facto linter, which emphasizes bad code practices, some of which can lead to vulnerabilities. However, it does not provide extensive security recommendations.
Bandit—you can use this tool to discover common security issues in Python code. Bandit processes each file, creates an AST node, and runs the appropriate plugin to test it.
Python IDEs like PyCharm and Wingware have these tools and others will be built in, as well as plugins for text editors that can provide security guidance.
Dynamic Analysis Security Testing Tool, or DAST Testing, is an application security solution that helps web developers discover specific vulnerabilities while running in staging or production environments.
DAST testing can find a wide range of vulnerabilities, including I/O validation issues that can make applications vulnerable to SQL injection attacks. The major benefit of DAST testing is that it can validate that a vulnerability is really exploitable—meaning that attackers can actually perform a successful SQL injection attack. DAST testing can also help identify misconfigurations and errors that could lead to a SQL injection attack.
DAST Testing for Python Applications with Bright Security
Bright Security helps automate the detection and remediation of many vulnerabilities including SQLi, early in the development process, across web applications and APIs.
By shifting DAST scans left, and integrating them into the SDLC, developers and application security professionals can detect vulnerabilities early, and remediate them before they appear in production. Bright Security completes scans in minutes and achieves zero false positives, by automatically validating every vulnerability. This allows developers to adopt the solution and use it throughout the development lifecycle.
Scan any web app, or REST, SOAP and GraphQL APIs to prevent SQL injection vulnerabilities – try Bright Security free.
What Is Interactive Application Security Testing (IAST)?
What is Interactive Application Security Testing (IAST)?
Interactive application security testing (IAST) solutions help detect and remediate vulnerabilities in web applications, as part of an organization’s security testing toolset.
IAST involves using dynamic testing, also known as runtime testing, to monitor application performance. IAST solutions instrument applications during runtime, using specialized sensors, to collect operational data and analyze user interactions with the application.
The IAST process can incorporate a combination of automated security tests, customized tests defined by the organization, or software composition analysis (SCA) to analyze open source components and find known vulnerabilities.
IAST tools deploy agents and sensors in the application during the post-build phase of the software development cycle. The agent works by observing the application’s performance and analyzing traffic flow. It maps external signatures or source code patterns to identify complex security vulnerabilities.
IAST tools provide a dashboard or web browser that lets you view testing reports in real-time and use customized reports that suit your CI/CD pipeline. You can also combine IAST results with other issues tracking tools.
IAST vs SAST vs DAST
Static application security testing (SAST) is a white box method that checks your code for vulnerabilities and flaws. It involves scanning code at rest and searching for known errors or an established set of rules. During the scan, a human or an automated program scans static code instruction by instruction and line by line.
Dynamic application security testing (DAST) is a black box method that checks running applications for security vulnerabilities and weaknesses. It involves looking for ways to attack the application without getting authorized access to the source code. A pentester or tool performing DAST simulates an external attack, typically by injecting or feeding malicious or faulty data to the tested software.
IAST employs both DAST and SAST techniques to test the inner workings of the source code, usually while the application is in development. IAST does not simulate an external attack and does not scan the entire codebase. Instead, DAST checks functionality at specific predefined points to achieve faster testing times. As a result, IAST does not provide complete coverage.
IAST Benefits and Drawbacks
Here are notable benefits of IAST:
Scans code in production—SAST tools often result in numerous false positives. For example, reporting a line of code can that was already addressed in another area of the code. IAST scan code in production while focusing only on issues that truly matter.
Scans code in development—IAST can help shift security checks to the left by checking specific issues during development. For example, IAST tools with IDE integration can offer quick feedback on features in development.
Quick remediation—IAST helps link issues with specific code locations. It enables developers to quickly click through an application to find specific problems and gain insights into quick remediation recommendations.
Here are notable drawbacks of IAST:
Programming-language dependent—IAST tools are often bound to specific technologies that may not fit your scenario. Additionally, some tools may require changing your code to include the vendor’s sensor modules.
Time intensive—IAST requires building and executing the tested application, which takes more time overall. If you use IDE plugins, you can leverage the quick feedback to catch issues during development. However, it can take longer when building big test suites that run on all production releases.
Does not provide complete code coverage—IAST scans only executed code to help reduce the number of false positives. It means the test does not cover all the code, including any code that was accidentally released without going through a quality assurance check.
Evaluate the following criteria when selecting an IAST solution:
Regulations and standards—IAST solutions must be able to scan for vulnerabilities and produce reports in line with the standards and regulations your organization complies with, such as GDPR, HIPAA, PCI DSS, and SOC 2.
Low false positives—an IAST solution should reduce the time needed to find and eliminate false positives. It should do so without requiring reconfiguration of the tool, custom services, or ongoing tuning.
Automated vulnerabilities identification—an IAST solution should accurately detect known vulnerabilities while your team performs functional tests. High severity bugs should create a ticket in your bug tracking system or break the build, while sending alerts to your developers.
Microservices support—microservices are a mainstream method for application development, and they introduce additional attack vectors. An IAST solution should allow you to assess multiple microservices from a single interface. Learn more in our guide to microservices security.
Ease DevOps agile workflows deployment—IAST tools must integrate into the existing DevOps pipeline and work seamlessly with standard build and testing tools.
Sensitive data tracking—IAST should help protect personally identifiable information (PII) and company IP. You should be able to automatically track sensitive information in your applications.
An Application Programming Interface (API) allows software applications to interact with each other. It is a fundamental part of modern software patterns, such as microservices architectures.
API security is the process of protecting APIs from attacks. Because APIs are very commonly used, and because they enable access to sensitive software functions and data, they are becoming a primary target for attackers.
API security is a key component of modern web application security. APIs may have vulnerabilities like broken authentication and authorization, lack of rate limiting, and code injection. Organizations must regularly test APIs to identify vulnerabilities, and address these vulnerabilities using security best practices. This article presents several methods and tools for API security testing, and a range of best practices that can help you secure your APIs.
API security involves securing data transferred through APIs, typically between clients and servers connected over public networks.
Businesses use APIs to connect services and transfer data. A compromised, exposed, or hacked API can expose personal data, financial information, or other sensitive data. Therefore, security is a critical consideration when designing and developing RESTful and other APIs.
APIs are vulnerable to security weaknesses in backend systems. If attackers compromise the API provider, they can potentially compromise all API data and functionality. APIs can also be exploited via malicious requests, if the API is not properly coded and protected.
For example, a denial of service (DoS) attack can take an API endpoint online or significantly degrade performance. Attackers can abuse APIs by scraping data or exceeding usage limits. More sophisticated attackers can inject malicious code to perform unauthorized operations or compromise the backend.
With the popularity of microservices and serverless architectures, almost every enterprise application depends on APIs for its basic functionality. This makes API security a core part of modern information security.
How is API Security Different From General Application Security?
Here are the main characteristics of traditional web security:
A castle and moat approach – the traditional network has a clear perimeter that controls access points. This perimeter allows or denies access to requestors and then assumes those that have entered are benign.
Mostly static protocols – incoming requests adhere to mostly static protocols, allowing administrators to configure a web application firewall (WAF) to enforce these protocols.
Clients use a web browser – the WAF can verify clients’ browser environments, and if the verification fails, it assumes the client is a bot that uses a headless browser or an emulator.
Examining requests to detect attacks – a traditional network can employ a WAF to block attempts at cross-site scripting (XSS). If it notices a large traffic volume from a single IP, the WAF can determine it is an attempted Distributed Denial of Service (DDoS) attack.
Here are key characteristics of API security that distinguish it from traditional security:
A castle with many openings and no moat – in the past, traditional networks needed to protect only common ports like 80 (HTTP) and 443 (HTTPS). Today’s web applications have numerous API endpoints that use different protocols. As APIs typically expand over time, even one API can make security a difficult endeavor.
Incoming request formats that change frequently – APIs evolve rapidly in a DevOps environment, and most WAFs cannot accommodate this level of elasticity. Every time an API changes, traditional security tools need manual tuning and reconfiguring, an error-prone process that consumes resources and time.
Clients often do not use a web browser – most service or microservice APIs are accessed by native and mobile applications or other services and software components. Since these clients do not use a browser, web security tools cannot use browser verification. Solutions that rely on browser verification to detect malicious bots usually find it difficult to exclude automated traffic from API endpoints.
Examining incoming requests does not guarantee detecting attacks – many API abuse attacks exploit requests that look legitimate.
OWASP API Top 10 Security Threats
The increase of API-related security threats in recent years has prompted the Open Web Application Security Project (OWASP) to release the API Security Top 10, which helps raise awareness of the most serious API security issues affecting organizations These are:
API1:2019: Broken Object-Level Authorization
APIs often expose endpoints handling object identifiers. Any function that accepts a user input and uses it to access a data source can create a Level Access Control issue, widening the attack surface. You should carry out object-level authorization checks for all such functions.
API2:2019: Broken User Authentication
Attackers often take advantage of incorrectly applied authentication mechanisms. They may compromise an authentication token or exploit flaws in implementation to pose as another user, on a one-time basis or permanently. If the system’s ability to identify the client/user is compromised, so is the overall API’s security.
API3:2019: Excessive Data Exposure
Developers often rely on the client side to filter the data before displaying it to the user. This can create serious security issues—data must always be filtered at the server side, and only the relevant information should be delivered to the client side.
API4:2019: Lack of Resources and Rate Limiting
APIs often don’t restrict the number or size of resources that the client/user can request. This can impact the performance of the API server, resulting in Denial of Service (DoS), and exposing authentication vulnerabilities, enabling brute force attacks.
API5:2019: Broken Function-Level Authorization
Authorization flaws often result from overly complex access control policies, or if there is no clear separation between regular and administrative functions. Attackers can exploit these vulnerabilities to gain access to a user’s resources or perform administrative functions.
API6:2019: Mass Assignment
Mass assignment typically results from the binding of client-provided data (i.e. JSON) to a data model based on an allowlist, without proper filtering of properties. Attackers can modify object properties in a number of ways—they can explore API endpoints, read the documentation, guess object properties, or provide additional properties through request payloads.
API7:2019: Security Misconfiguration
Security misconfiguration often results from inadequate default configurations, ad-hoc or incomplete configurations, misconfigured HTTP headers or inappropriate HTTP methods, insufficiently restrictive Cross-Origin Resource Sharing (CORS), open cloud storage, or error messages that contain sensitive information.
API8:2019: Injection
Injection flaws (including SQL injection, NoSQL injection, and command injection) involve data that is sent to an interpreter from an untrusted source via a command or query. Attackers can send malicious data to trick the interpreter into executing dangerous commands, or allow the attacker to access data without the necessary authorization.
API9:2019: Improper Asset Management
Compared to traditional web applications, APIs typically expose more endpoints and thus require structured, up-to-date documentation. Issues such as exposed debug endpoints and deprecated API versions can increase the attack surface. This can be mitigated by creating an inventory of deployed API versions and properly configured hosts.
API10:2019: Insufficient Logging and Monitoring
Attackers can take advantage of insufficient logging and monitoring, as well as ineffective or lacking incident response integration, to persist in a system, deepen their hold and extract or destroy more data. It typically takes over 200 days to detect a persistent threat, and breaches are usually discovered by an external party—highlighting the critical importance of effective API monitoring.
REST API Security vs SOAP Security
There are two main architectural styles used in modern APIs:
SOAP—a highly structured message protocol that supports multiple low-level protocols.
REST—a simpler approach to APIs using HTTP/S as the transport protocol, and typically using JSON format for data transfer.
Both types of APIs support HTTP requests and responses and Secure Sockets Layer (SSL), but the similarity ends there.
SOAP API security
SOAP offers extensions to the protocol that address security matters
SOAP is based on W3C and OASIS recommendations, including SAML tokens, XML encryption, and XML signatures.
SOAP supports the Web Services (WS) specifications, which lets you use security extensions like WS-Security, which provides enterprise-grade security for web services
SOAP supports WS-ReliableMessaging which provides built-in error handling
REST API security
REST APIs do not have any built-in security capabilities—security depends on the design of the API itself.
Security must be built in for data transmission, deployment, and interaction with clients
REST APIs do not have built-in error handling and need to resend data when an error occurs.
A common architectural choice is to deploy REST APIs behind an API gateway. Clients connect to the gateway, which acts as a proxy, not directly to the REST API. This allows many security concerns to be addressed by the API gateway.
In conclusion, SOAP APIs are more secure by design, but REST APIs can be made secure, depending on their implementation and the architecture selected.
GraphQL is a query language that describes how clients can request information via an application programming interface (API). Developers can use GraphQL syntax to request specific data and receive it from a single source or multiple sources. Once a client defines the required data structure for a request, a server returns data using that exact structure.
Since clients can craft highly complex queries, the server must be ready to properly handle them. The server should be able to handle abusive queries from malicious clients, as well as large queries by legitimate clients. If the server does not handle these scenarios properly, the client might take the server down.
Here are a several strategies that can help you mitigate GraphQL security risks:
Timeout – a timeout can help you defend against large queries. It is the simplest strategy because it does not require the server to know any details about incoming queries. The server only needs to know the maximum time allowed per query.
Maximum query depth – can help you prevent clients from abusing query depth. Maximum query depth is the analysis of a query document’s abstract syntax tree (AST) to determine what is acceptable. The GraphQL server can then use this depth to accept or reject requests.
Query complexity – query depth is not always enough to understand the scope of a GraphQL query. This usually happens when certain schema fields are more complex to compute than others. Query complexity can help you define the level of complexity of these fields, and restrict queries that exceed a complexity threshold.
Throttling – the above options can stop large queries, but they cannot stop clients that make many medium-sized queries. For GraphQL, even a few queries could be too much to handle, if queries are expensive. You can determine the server time needed to complete each type of query, and use this estimation to throttle queries.
Find out more tricks for improving security with GraphQL testing.
Methods Of API Security Testing
You can use the following methods to manually test your APIs for security vulnerabilities.
Test for Parameter Tampering
In most cases, parameters sent through API requests can be easily tampered with. For example, by manipulating parameters, attackers can change the amount of a purchase and receive products for free, or trick an API into providing sensitive data that is not authorized for the user’s account.
Parameter tampering is often performed using hidden form fields. You can test for the presence of hidden fields using the browser element inspector. If you find a hidden field, experiment with different values and see how your API reacts.
Test for Command Injection
To test if your API is vulnerable to command injection attacks, try injecting operating system commands in API inputs. Use operating system commands appropriate to the operating system running your API server. It is recommended to use a harmless operating system command which you can observe on the server—for example, a reboot command.
For example, if your API displays content via a URL, you can append an operating system command to the end of the URL to see if the command is executed on the server:
Fuzzing means providing random data to the API until you discover a functional or security problem. You should look for indications that the API returned an error, processed inputs incorrectly, or crashed.
For example, if your API accepts numerical inputs, you can try very large numbers, negative numbers, or zero. If it accepts strings, you can try random SQL queries, system commands, or arbitrary non-text characters.
Test for Unhandled HTTP Methods
Web applications that communicate using APIs may use various HTTP methods. These HTTP methods are used to store, delete, or retrieve data. If the server doesn’t support the HTTP method, you will usually get an error. However, this is not always the case. If the HTTP method is unsupported on the server side, this creates a security vulnerability.
It is easy to test if HTTP methods are supported on the server side, by making a HEAD request to an API endpoint that requires authentication. Try all the common HTTP methods—POST, GET, PUT, PATCH, DELETE, etc.
Securing production APIs, especially those that have a regular development and release process, requires automated tools. The following open source tools can help you design security-related test cases, run them against API endpoints, and remediate issues you discover. They can also discover business logic vulnerabilities, which can also be an opening for attackers.
Postman
Postman is an API development platform. Its key features include:
Automating manual API tests
Integrating tests into the CI/CD pipeline
Simulating expected behavior of API endpoints and responses
Checking API performance and response times
Enables collaboration between developers with built-in version control
Swagger
Swagger is an open source toolkit that can help you create RESTful APIs. Its enables two API development styles:
Top-down API design, letting you build an API in Swagger and then generate code from specifications
Bottom-up API design, in which Swagger takes existing code and generates documentation about API operations, parameters and outputs
JMeter
JMeter is a load testing tool, which can also be used for security testing. Key features include:
Inputting CSV files and using them for load testing—this lets you perform tests with different values to simulate risky scenarios and cyber attacks.
Embedding API tests into the build process with Jenkins
Advanced performance testing, with the ability to replay test results
SoapUI
Soap UI is a popular API functional testing tool. Its key features include:
A large library of functional testing elements that let you automate API tests
Fully customizable, provides source code so you can build your own features
Easy drag and drop interface to create tests
Lets you reuse existing load test or security scans for functional tests
In the pro package, lets you perform data-driven testing, simulating how users work with the API using spreadsheets or databases
Karate
Karate DSL is a Java API testing tool using the behavior-driven development (BDD) approach. Its key features include:
Writing BDD for APIs with ready-made step definitions
Generates standard Java reports
Does not require Java knowledge to write tests for Java-based APIs
Enables multi-threaded execution
Supports switching configuration between staging and production
Fiddler
Fiddler is a tool that monitors and replays HTTP requests, with an API testing extension for .NET, Java, Ruby, and other popular frameworks. Its key features include:
Debugging requests from any type of client—including Windows, MacOs, Linux, and mobile devices
Tests cookies, cache, and headers in client-server communication
Provides a convenient UI for grouping and organizing API requests
Creates mock requests and responses with no code changes
Use the following best practices to improve security for your APIs.
Identify Vulnerabilities
The only way to effectively secure an API is to understand which parts of the API lifecycle are insecure. This can be complex, especially if your organization operates a large number of APIs. It is important to consider the entire API lifecycle—the API must be treated as a software artifact, which goes through all the stages of a software product, from planning through development, testing, staging, and production.
Leverage OAuth
One of the most important aspects of API security is access control for authentication and authorization. A powerful tool for controlling API access is OAuth—a token-based authentication framework that allows third-party services to access information without exposing user credentials.
Encrypt Data
All data managed by an API, especially personally identifiable information (PII) or other sensitive data protected by compliance standards and regulations must be encrypted. Implement encryption at rest, to ensure attackers who compromise your API server cannot make use of it, and encryption in transit using Transport Layer Security (TLS). Require signatures to ensure that only authorized users can decrypt and modify data provided by your API.
Use Rate Limiting and Throttling
As APIs become popular, they become more valuable to attackers. APIs are now a prime target for denial of service (DoS) attacks. Set rate limits on the method and frequency of API calls to prevent DoS attacks, and protect against peak traffic, which can affect performance and security. Rate limiting can also balance access and availability by regulating user connections.
Use a Service Mesh
Like API gateways, service mesh technology applies different layers of management and control when routing requests from one service to the next. A service mesh optimizes the way these moving parts work together, including correct authentication, access control and other security measures.
As the use of microservices increases, service meshes are especially important. API management is shifting to the service communication layer, and service meshes can provide automation and security for large deployments with multiple APIs.
Traditionally, networks had a perimeter and elements “inside” it were trusted, while elements “outside” were not. Networks are no longer that simple, with insider threats becoming prevalent, and legitimate users often connecting from outside the network perimeter. This is especially true for public APIs with users from all over the world, accessing internal software components and sensitive data.
A zero trust philosophy shifts the security focus from location to specific users, assets, and resources. It can help you ensure that APIs always authenticate users and applications (whether inside or outside the perimeter), provides the least privileges they actually need to perform their roles, and closely monitors for anomalous behavior.
Test Your APIs with Dynamic Application Security Testing (DAST)
Bright has been built from the ground up with a dev first approach to test your web applications, with a specific focus on API security testing.
With support for a wide range of API architectures, test your legacy and modern applications, including REST API and GraphQL.
To compliment DevOps and CI/CD, Bright empowers developers to detect and fix vulnerabilities on every build, reducing the reliance on manual testing by leveraging multiple discovery methods:
HAR files
OpenAPI (Swagger) files
Postman Collections
Start detecting the technical OWASP API Top 10 and more, seamlessly integrated across your pipelines via:
Bright Rest API
Convenient CLI for developers
Common DevOps tools like CircleCI, Jenkins, JIRA, GitHub, Azure DevOps, and more
See Additional Guides on Key Application Security Topics
Together with our content partners, we have authored in-depth guides on several other topics that can also be useful as you explore the world of application security.
DevSecOps Best Practices for a Stronger Security Culture
In today’s fast paced agile world, keeping data safe should be everyone’s job, with collaborative and robust security processes in place. To ensure success, especially with multiple iterations of software being pushed into production daily, we need to have a framework in place that will bring the required people, processes and tools together. One such framework is DevSecOps.
Implementing a DevSecOps framework and culture into your business will reduce the need for large-scale security fixes downstream by enabling your teams to make better decisions at the very beginning of their projects.
We will be building on our in-depth article on DevSecOps to focus on six best practices you should follow to implement a DevSecOps framework in your organization, covering
Speed and automation is crucial for DevOps. The time it takes for code to be pushed to production is imperative and security testing must be part of that workflow, without slowing you down. Developers are releasing 100 times more code than 10 years ago and are introducing security vulnerabilities at the same rate too. Manual tests simply can’t keep up with the speed at which organizations release code today and create too many bottlenecks.
Include automated security controls and innovative security scanning (like Bright’s) early and everywhere in the development lifecycle.
2. Check code dependencies
Despite growing concerns, enterprises are using open-source third-party components more than ever before. With the tight schedule and load of tasks, developers often don’t have the time to analyze all the components they use. We need an automated process for managing those components.
For DevSecOps code dependency checks are fundamental, and tools like OWASP Dependency-Check or Snyk can help you make sure you don’t use components with known vulnerabilities in them.
3. One step at a time
When implementing new tools like SAST to a CI/CD chain, security teams often turn on detection of all supported vulnerabilities, causing frustration and possible conflict with developers. The high rate of false positives with these tools can also impact developer adoption.
Start introducing the tool by setting it up so it detects only a few vulnerability categories, such as SQL Injection. This will give your developers time to get familiar with the tool and understand how it helps them detect vulnerabilities while coding. That will increase adoption of the tool, or reduce the likelihood of it being rejected out of hand.
One step at a time – by disrupting things you will just slow down developers and cause possible conflict.
4. Pick your tools carefully
When choosing the right security tools for your organization, you need to consider these main features:
Integration One of the key aspects you have to consider is the tools ability to seamlessly and easily integrate into the development pipeline, with a direct feedback loop for developers while also providing the security team and management with full visibility.
Developer First Mindset With DevOps and CI/CD, security tooling needs to be built with developers in mind – for security scanners, developers need to be able to initiate scans quickly, without leaving their existing toolset, controlling scans via code, or to have global configuration files for security governance.
With most legacy tools being built for security professionals, they can be hard to use, configure and understand the output. Ensuring the tooling truly focuses on enabling developers will maximize success, by leveraging your largest team to spearhead your security efforts
Speed and Accuracy Without automation and speed, your DevOps and CICD pipelines will either grind to a halt or be ineffective. Speed and accuracy of your security tests and findings respectively is paramount to ensure success. The need to run short, fast. incremental scoped defined tests on every build / commit is important, but the accuracy (or inaccuracy in most cases) can really set you back. Manual validation of security finings is a major bottleneck that compounds security and technical debt and makes it impossible to understand your true cyber posture and to prioritize remediation of fixes.
Ensuring your tool minimizes the number of false positives (or like in Bright’s case, removes them completely), means you can start to trust the output, create tickets and start to remediate issues immediately.
Although at number five on our list, this step should be taken, according to SANS Institute, before shifting to DevSecOps. With threat modeling, your security team will not only get a better understanding of the threats, types and sensitivities of your assets, but also what controls for protecting those assets are already in place and/or lacking. A threat modeling exercise will also help your security team to identify any gaps in your controls that need to be addressed.
Threat modeling can help you identify issues in architecture and design that other approaches might have missed. Unfortunately, threat modeling, unlike almost every other facet of DevSecOps, can’t be automated. For that reason it is often considered as a burden for DevSecOps. Organizations are worried that it could slow down the velocity of a CI/CD environment. But that doesn’t mean you should skip or ignore it.
Threat modeling is crucial for your DevSecOps efforts. It helps your developers change their perspective and look at their software as an attacker would do.
6. Secure coding training
Although historically a challenge was getting the needed management buy-in, investment and time to train development teams on secure coding practices, this is increasingly becoming more popular and rightly so.
Developers never intend to create insecure software, but organizations prioritize the speed at which new features are released and that they work properly, over being secure. Providing the right training to developers to prevent them from introducing security bugs into their code is a great way of being secure by design, especially when coupled with a dev-first security scanner.
What makes Bright Security the perfect tool for DevSecOps
Traditional (legacy) security scanners are built for security professionals, penetration testers and cyber experts, NOT developers. Bright has been built from the ground up to enhance DevSecOps with a developer first approach, enabling you to shift-left:
Bright integrates early into the SDLC: Unlike traditional DAST tools, Bright integrates early into the SDLC allowing you to detect and remediate vulnerabilities early and often
Bright tests every aspect of your apps and APIs: Bright is capable of scanning any target, whether web / internal apps, APIs (REST, SOAP, GraphQL, and more) or mobile
Bright seamlessly integrates with the tools and workflows you already use: Bright works with your existing CI/CD pipelines – it triggers scans on every commit, pull request or build with unit tests
Developers can spin up, configure and control scans with code: One file. One command. No UI needed
NO false-positive: Bright automatically validates every security finding so you don’t have. Start trusting your output
Penetration testing (pentesting), is a cybersecurity technique used by organizations to identify and remediate security vulnerabilities. Organizations hire ethical hackers to imitate the tactics and behaviors of external attacks. This makes it possible to evaluate their potential to compromise computer systems, networks, or web applications.
Organizations also use penetration testing to ensure compliance—some compliance standards and regulations require a penetration test to prove that the organization’s systems are secure.
1. Network Penetration Testing
Network penetration testing finds and exploits the most exposed vulnerabilities in network infrastructure such as servers, firewalls, and switches. This type of testing can help protect your business from common network-based attacks, such as:
Web application penetration testing is used to find vulnerabilities in web-based applications. It uses a three-step process:
Reconnaissance—discovering information about web servers, operating systems, services, resources, and more used by the web application
Discovery—finding vulnerabilities in the web applications and planning attack vectors to be used in the penetration test.
Attack—exploiting a vulnerability to gain unauthorized access to the application or its data.
Penetration testing of web applications can identify security vulnerabilities in databases, source code, and backend networks of web-based applications. It can not only identify vulnerabilities but also help prioritize them and provide solutions to mitigate them.
Wireless communications are services that allow data to move in and out of networks and must be protected from unauthorized access and data exfiltration. Wireless penetration testing is used to identify risks associated with wireless networks and evaluate weaknesses such as:
Deauthentication attacks
Misconfiguration of wireless routers
Session reuse
Unauthorized wireless devices
4. Physical Penetration Testing
If a threat actor has physical access to a server room or other sensitive facility, they can potentially compromise the entire network, which can have devastating effects on business, customers, and partnerships. Physical penetration testing can help secure an organization’s physical assets from threats such as social engineering, tailgating, and badge cloning.
Physical penetration testing finds weaknesses in physical controls such as locks, doors, cameras, or sensors, and allows the organization to quickly remediate defects.
5. Social Engineering Penetration Testing
When it comes to security, users are often considered the weakest link of the security chain, and are a common target for attackers. Social engineering penetration testing focuses people and processes in the organization and the security vulnerabilities associated with them. It is performed by ethical hackers who attempt social engineering attacks which are commonly experienced in the workplace, such as phishing, USB dropping, and spoofing.
The goal is to identify vulnerable individuals, groups, or processes, and to develop pathways for improving security awareness.
6. Client-Side Penetration Testing
Client-side penetration testing tests can uncover security vulnerabilities in software running on client computers, such as web browsers, media players, and content creation software packages (such as MadCap Flare, Adobe Framemaker, or Adobe RoboHelp). Attackers often compromise client-side software to gain access to company infrastructure.
Perform client-side testing to identify specific network attacks, such as:
Cross-site scripting attacks (XSS)
Clickjacking attacks
Cross-origin resource sharing (CORS)
Form hijacking
HTML injection
Open redirection
Malware infection
7. IoT Penetration Testing
IoT penetration testing looks for security vulnerabilities in connected ecosystems, including vulnerabilities in hardware, embedded software, communication protocols, servers, and web and mobile applications related to IoT devices.
The types of tests conducted on hardware, firmware, and communication protocol depend on the connected device. For example, some devices may require data dumping through electronic components, firmware analysis, or signal capture and analysis.
8. Mobile App Penetration Testing
Mobile application penetration testing is performed on mobile applications (excluding mobile APIs and servers), including both static and dynamic analysis:
Static analysis extracts source code and metadata and performs reverse engineering to identify weaknesses in application code.
Dynamic analysis finds application vulnerabilities while the application is running on a device or server.
9. Red Team Penetration Testing
Red team penetration is an advanced testing technique based on military training exercises. It uses an adversarial approach, allowing organizations to challenge their security policies, processes, and plans. Blue teaming, or “defensive security,” involves detecting and withstanding red team attacks and real-life adversaries.
Red teaming combines physical, digital, and social contexts to simulate a comprehensive real-life attack scenario, making it distinct from standard penetration testing. It encompasses tasks related to the various types of penetration testing. While a standard pentest aims to identify as many vulnerabilities as possible in a set timeframe, it is typically limited by artificial restrictions such as the task scope.
Regular penetration tests are important, but they don’t provide realistic conditions, such as combined attack techniques. Red teaming allows security teams to assess the overall environment and understand how its components function together. It requires critical thinking to identify new, complex vulnerabilities.
Red team assessments are generally more time-consuming than standard penetration tests, often taking several months to complete. This complex nature makes red teaming a rare operation, viable only for large organizations.
Picking the right penetration test usually comes down to understanding where the risk actually sits today. That’s something teams often skip over while rushing to “just run a pen test.”
When a customer-facing application or API is about to go live, testing external attack paths is the obvious place to start. If the concern is internal access, growing identity complexity, or how remote users connect into the environment, infrastructure, or Active Directory, testing tends to surface more relevant issues.
Red team exercises come into play when leadership wants to understand how different weaknesses chain together, not just whether a single bug exists.
Budget and timing matter too. A full red team once a year might sound good on paper, but it won’t help much if major changes ship every month. In fast-moving environments, narrower but more frequent tests often provide better coverage. The “right” test is the one that matches how your system is actually used – not the one that looks best in a compliance report.
Penetration Testing vs Vulnerability Scanning: What’s the Difference?
Vulnerability scanning is about breadth. It looks for known issues across a large surface area and does it quickly. That’s useful for hygiene and visibility, but it stops at identification. Most scanners can’t tell you whether an issue is exploitable in your specific environment.
Penetration testing is about depth. A tester takes a smaller set of targets and tries to break them the way an attacker would. That means chaining issues, abusing logic, and working around controls instead of just flagging missing patches. Scanners tell you what might be wrong. Pen tests show you what can actually be done. Both have a place, but they answer very different questions.
Common Penetration Testing Tools by Type
Most penetration testers don’t rely on a single tool. Web application testing often involves intercepting proxies to understand requests and responses, combined with custom scripts to test edge cases that scanners miss. API testing tools are common now, especially for environments that are mostly backend-driven.
For infrastructure and network testing, tools that enumerate services, credentials, and misconfigurations are standard, but a lot of the real work still happens manually. Cloud and identity testing has its own ecosystem of tools focused on permissions, trust relationships, and lateral movement. What matters more than the tool itself is how it’s used. Skilled testers spend more time thinking than clicking buttons.
Reporting Best Practices After Penetration Tests
A penetration test report should help teams fix problems, not just document that problems exist. The most useful reports explain how an issue was found, why it matters, and what makes it exploitable in that environment. Screenshots and request traces are far more valuable than generic descriptions.
Prioritization is critical. If everything is marked “high,” nothing is. Good reports separate theoretical risk from issues that enable real impact. They also avoid dumping raw tool output on engineering teams without context. When developers can clearly see the attack path, fixes happen faster. When they can’t, reports tend to get ignored.
Complementing Penetration Testing with Dynamic Application Security Testing (DAST)
Bright Security significantly improves the application security pen-testing progress. By providing a no-false positive, AI powered DAST solution, purpose built for modern development environments the pen-testing process can be automated and vulnerabilities can be found faster and at a lower cost. Moreover, integrating Bright Security into DevOps environments enables you to run DAST scans as part of your CI/CD flows to identify a broad set of known (7,000+ payloads) security vulnerabilities early in the development process.
In addition to detecting technical vulnerabilities, Bright Security’s unique ability to detect business logic vulnerabilities offers broader coverage and detection that any other automated solution.
Network penetration testing is an attempt by an ethical hacker to breach an organization’s network without doing harm. The objective is to identify security weaknesses in the network and its security controls, report on them, and allow the organization to remediate them.
Modern networks are extremely complex, with a combination of WAN, LAN, and wireless networks, a large number of endpoints including servers, workstations, mobile devices and internet of things (IoT) devices, and security technologies like firewalls and intrusion prevention systems (IPS). Any of these could be a weak link that allows attackers to penetrate the network.
A network penetration test takes the perspective of an outside attacker, scanning the network to identify vulnerabilities, and actually exploiting them to prove their possible impact on the business.
Here are some of the common threats that can be tested with network penetration testing.
Malware
Malware is malicious software that can be used to attack computer systems. Trojans, ransomware, and spyware, are common examples of malware. Hackers can use malware to steal or copy sensitive data, block access to files, compromise or damage operational systems and datasets.
Phishing
Phishing is a tactic in which attackers impersonate a reputable entity or individual through email or other forms of communication. Attackers often use phishing emails to distribute malicious links and attachments that can further their goals. These links or attachments typically send the user to a malicious website or directly deploy malware. The end goal of phishing is to extract login credentials, account information, or other sensitive information from victims.
Traditionally most phishing attacks were conducted by email, but attackers are increasingly performing attacks via other forms of communication, including social networks, SMS messages, and even voice calls.
DDoS Attacks
In a distributed denial of service (DDoS) attack, multiple infected computer systems attack a target, denying service for the system’s legitimate users. DDoS can target servers, websites, or other network resources. It is performed by creating a large number of fake connection requests, malformed packets, or other illegitimate traffic that floods a target system and can cause it to slow down, crash, or shut down.
Advanced Persistent Threats (APTs)
An APT is a long-term targeted cyberattack that allows an intruder to gain access to a network and remain undetected for a long period of time. APT attacks are typically aimed at stealing data rather than disrupting the target organization’s network.
The goal of most APT attacks is not to get in and out as quickly as possible, but rather to achieve and maintain continuous access to the target network. Because executing APT attacks can be very labor-intensive and resource-intensive, hackers often choose high-value targets such as countries and large corporations, from which they can steal information over an extended period of time. APT attacks are commonly conducted by large, organized cybercrime groups or state-sponsored hackers.
Drive-by Downloads
In a drive-by download attack, malware is accidentally downloaded to a user’s computer or mobile device, leaving them vulnerable to cyberattacks. This attack is especially severe because the user does not need to click anything or open a malicious email attachment to get infected, and so it can affect even security conscious individuals.
Drive-by downloads exploit vulnerabilities in applications, operating systems, or web browsers (these may be zero day vulnerabilities not yet addressed by the vendor, or known vulnerabilities where the user or the organization failed to apply a security update).
DNS Attack
A DNS attack is a vulnerability that could allow an attacker to exploit Domain Name System (DNS) vulnerabilities.
Although DNS is very powerful, it is designed for ease of use, not security. There are many types of DNS attacks in use today. Some attacks manipulate communication between a DNS client and server. Others use stolen credentials to log into your DNS provider’s website and redirect DNS records to malicious websites.
External vs. Internal Network Penetration Testing
External Penetration Testing
Traditionally, external threats were often considered more important than internal threats. Most organizations agree that anything exposed to the Internet needs some form of security testing, and possibly the most rigorous type of testing is penetration testing.
If an external host is compromised, it can lead to an attacker digging deeper into the internal environment. If an external device is the target of an attack, like a hacker looking for a public-facing SFTP/FTP server that stores client data, these devices must also be protected.
External network penetration testing focuses on the perimeter of your network and identifies any deficiencies that exist in public-facing security controls. When performing external penetration testing, the testers mimic real scenarios as best as possible to identify as many potential vulnerabilities as possible.
External network penetration testing techniques include the following:
Host and service discover, port scanning and querying
Attempting to gain access to public-facing systems using default passwords, brute force, password cracking, or other techniques
Network sniffing and traffic monitoring
Spoofing or deceiving servers and network equipment
Using buffer overflow or similar attacks for remote code execution
Running exploits for discovered vulnerabilities
Changing configuration of running systems
Denial of Service (DoS)
Privilege escalation and lateral movement when gaining access to any internal systems
Internal Penetration Testing
Insider threats are a growing concern at most organizations. An insider threat could be a disgruntled worker, previously terminated employees, or someone trying to steal trade secrets. An insider threat could also be someone who does not have malicious intent—for example, negligent or careless employees, human errors and misconfigurations can all result in a network compromise.
Internal network penetration testing targets the networked environment that lies behind public-facing devices. This type of penetration test is designed to identify and exploit issues that can be discovered by an attacker who has gained access to your internal network.
Internal penetration testing techniques include:
Scanning for internal subnets, domain servers, file servers, printers, switches
Privilege escalation and lateral movement
Identifying vulnerable devices, services, or operating systems on the local network
Deploying malware such as trojans and rootkits to gain persistent access
Network penetration testing typically follows four stages: reconnaissance, discovery, exploitation, and analysis. The following discussion mainly refers to external penetration testing, but the process for internal testing is similar.
Reconnaissance
The reconnaissance stage involves scanning systems and uncovering potential weaknesses and vulnerabilities, like an external attacker would do. This has two aspects:
Technology vulnerabilities—the penetration tester looks for weaknesses in network ports, peripherals, software, or network services hackers can use to get into your systems. This process is very useful for vulnerability assessment and provides an external perspective on security weaknesses in the environment.
Human vulnerabilities—social engineering vulnerabilities include common phishing scams and theft of login credentials. Penetration testers can try these tactics and see if the company’s employees are vulnerable to social engineering. This can help identify problems and raise awareness of security policies among employees.
Discovery
During the discovery phase, penetration testers use information from the reconnaissance phase to perform real-time testing using pre-coded or customized scripts to identify possible security issues and see if they are easily exploitable. The objective is to identify the possible attack vectors and decide which one the tester will use during exploitation.
Exploitation
In the exploit phase, penetration testers use the information obtained in the discovery phase, such as vulnerabilities and entry points, to begin testing exploits on vulnerabilities they discovered in network devices or IT systems. The goal of the exploit phase is to break into the network environment, evade detection, and demonstrate a capability to do damage (for example, by gaining access to sensitive data).
Analysis
At the end of the test, the penetration tester documents their process and findings, and prepares a penetration test report. In most cases, reports include vulnerabilities identified and exploited, sensitive data accessed, and how long ethical hackers managed to avoid detection.
The report must provide actionable information that can allow the organization to patch vulnerabilities and protect against future attacks.
Complementing Penetration Testing with Dynamic Application Security Testing (DAST)
Bright Security enables organizations to automate black box testing for a long list of vulnerabilities across both applications and APIs. These tests include both technical vulnerabilities and business logic vulnerabilities. This combination goes a long way towards providing unparalleled coverage that previously could only be achieved by conducting manual penetration testing.
Moreover, the automated solution enables organizations to run targeted scans early in the SDLC and remediate issues before they make it to production. This is far superior to having to detect vulnerabilities in a production environment with manual tests.
Web Application Security: Threats and 6 Defensive Methods
What Is Web Application Security?
Web application security is the practice of detecting and preventing cyber attacks on websites, and more importantly—building websites that are secure to begin with. This includes a set of security controls built into web applications to protect them from a growing variety of cyber threats.
Web applications inevitably contain bugs and misconfigurations, and some of these are security vulnerabilities that can be exploited by attackers. Web application security helps address these vulnerabilities by leveraging secure development practices, implementing security testing throughout the software development lifecycle (SDLC), resolving design-level defects and avoiding security concerns during deployment and runtime.
This is part of an extensive series of guides about cybersecurity.
Web security testing focuses on identifying security vulnerabilities in web applications and their configurations. Its primary objective is the application layer. Testing web application security often involves delivering various input types to provoke errors and cause unexpected system behavior. These “negative tests” investigate whether the system is performing tasks it isn’t designed to execute.
Additionally, web security testing extends beyond evaluating the security features, such as authentication and authorization, implemented in the application. It’s equally significant to test other features for secure implementation, for example—business logic, proper input validation, and output encoding.
Here are some of the major risks facing web applications today.
Injection
This security risk occurs when untrusted data is sent to an interpreter via a command or query. An attacker injects malicious code that looks like normal code, and can trick the interpreter into executing unexpected commands or accessing data without proper permissions.
An injection attack on a web application can bypass authorization mechanisms, resulting in exposure of valuable data or complete compromise of the system. Common injection flaws include LDAP, NoSQL, and SQL injection.
Denial of Service (DoS) and Distributed Denial-of-Service (DDoS)
In a DoS attack, attackers generate fake traffic through different vectors to overload the target server or surrounding infrastructure. If the server cannot handle incoming requests efficiently, it slows down and eventually refuses to process incoming requests from legitimate users. A DDoS attack is the same thing at a much larger scale, leveraging botnets of thousands or millions of devices controlled by the attacker.
CSRF tricks victims into making unwanted requests, leveraging existing authentication. An attacker can use the user’s account privileges to impersonate the user and perform operations on their behalf.
If a user account is compromised, an attacker can steal, destroy, or modify sensitive information. Attackers typically target accounts with high privileges, such as accounts belonging to administrators or executives.
XSS allows hackers to inject client-side scripts into web pages to intercept user session access, impersonate users, access sensitive information, tamper with websites, or redirect URLs to malicious websites. This flaw occurs whenever an application embeds untrusted data in a web page, or updates a website with user inputs via browser-generated HTML or JavaScript, without proper validation.
This is one of the most common risks to web applications. It occurs when security controls are not set correctly in a web application or the surrounding infrastructure.
For example, security configuration errors can be unpatched known vulnerabilities, cloud storage exposed to the Internet with no authentication, insecure default configurations left as-is, misconfigured HTTP headers, or unnecessarily detailed error messages that divulge sensitive information to attackers.
Application security professionals must ensure the secure configuration of all applications, frameworks, operating systems, and libraries. It is important to ensure that these are also updated and patched in a timely manner.
Many web applications have misconfigured XML processors, which evaluate external entity references in XML files. An attacker can exploit external entities to expose internal server files, perform internal port scanning, use a web server for denial of service (DoS) attacks, and perform remote code execution.
Deserialization is the process of recreating data objects from a stream of bytes. Insecure deserialization occurs when untrusted code, created by an attacker, exploits vulnerabilities in the programming language’s deserialization mechanisms. In severe cases, this can enable remote code execution (RCE). Even if the vulnerability does not lead to RCE, it might still be exploited to perform escalation of privileges, code injection attacks, and replay attacks.
Tools You Can Use to Defend Against Web Application Threats
There are two main methods to defend against web application vulnerabilities—prevention or blocking. Ideally, organizations should employ both methods.
Here are key tools to help prevent web application vulnerabilities:
Static application security tests (SAST)—involves analyzing the application source code during development. SAST tools help detect coding and design issues that can lead to vulnerabilities. Learn more in our guide to SAST
Software composition analysis (SCA)—involves analyzing applications to identify open source software (OSS) and third-party components containing known vulnerabilities or licensing restrictions.
Interactive application security testing (IAST)—involves observing application behavior, such as input, output, data flow, and logic. It requires deploying an IAST agent in the application to conduct a runtime analysis of the code, data flow, and memory.
Dynamic application security tests (DAST)—involves analyzing code in runtime, including servers and underlying application frameworks. It requires a manual configuration of the DAST for each application. Learn more in our guide to DAST
Here are key tools to help block web application attacks:
Web application firewall (WAF)—protects web applications against malicious HTTP traffic. It places a filter barrier between attackers and the targeted server to block attacks such as SQL injection, CSRF, and XSS.
Runtime application self-protection (RASP)—detects and blocks attacks by employing in-application instrumentation. You can use an SDK to integrate RASP directly into your codebase or deploy an agent to the host at runtime.
Effectively validating user inputs is crucial for mitigating web application security threats like SQL injection and cross-site scripting (XSS). Verify all data submitted to your application for type, length, format, and range before processing to prevent attackers from injecting malicious code into your system.
Implementing Transport Layer Security (TLS) with the latest recommended cipher suites and protocols is essential for secure data transmission. Keep TLS configurations current to maintain robust encryption standards.
In addition to TLS for data transmission, securely storing user passwords is important. Use strong cryptographic hash functions like SHA-256 or SHA-512 for password encryption before adding them to your database.
3. Enhance Authentication and Authorization
Implement advanced authentication methods like multi-factor authentication (MFA) to ensure authorized access to your web applications. Set complex password requirements and limit failed login attempts to safeguard against brute force attacks. Implement role-based access control (RBAC) mechanisms to provide the appropriate permissions based on users’ roles within the organization.
APIs are essential in modern web applications but may introduce security vulnerabilities if improperly managed. Ensure all APIs used in your application have adequate authentication and authorization measures and communicate through encrypted channels. Monitor API usage routinely and analyze access logs for unusual activity or potential vulnerabilities.
5. Record Code Changes
Maintaining accurate records of code changes is crucial for monitoring updates, bug fixes, and new features in your web application. This practice fosters transparency within development teams and helps swiftly identify potential security problems caused by recent modifications. Use version control systems like Git to enable efficient developer collaboration while maintaining a structured history of code adjustments.
6. Employ Dynamic Testing for Application Security Validation
Using dynamic testing with tools like DAST is another best practice for web application security. Dynamic testing tools can detect numerous issues such as injection attacks, cross-site scripting (XSS), broken authentication and session management, insecure direct object references, and more. Incorporate DAST into all development lifecycle stages, from early testing and staging to production, for shifting security left.
Learn more about SAST in our detailed guide to snyk cli.
Securing Web Applications with Bright Security
Bright is a developer-first Dynamic Application Security Testing (DAST) scanner that can test your applications and APIs (SOAP, REST, GraphQL), enabling you to bake security testing across your development and CI/CD pipelines.
Detect the OWASP (API) Top 10, Mtre 25 and more, including Business Logic Vulnerabilities. You can easily reduce your security and technical debt by scanning early and often, on every build, to be secure by design.
With NO false positives, there is no need for manual validation of security findings, removing costly and time consuming human bottlenecks that cripple your rapid releases and drain your security team’s limited resources.
See Additional Guides on Key Cybersecurity Topics
Together with our content partners, we have authored in-depth guides on several other topics that can also be useful as you explore the world of cybersecurity.
Security should be a crucial part of any application you are working on. In this article we are going to cover the web application security best practices you should consider when working on your next project, but before we do that, let us quickly cover why security is so important:
Why is it so crucial to have strong application security?
Loss of customer data
Customers trust you with their data. It’s your responsibility to keep that data secure from malicious users and attackers.
Loss of revenue
Service outages and downtime can cost your business a lot of money, let alone the reputational damage that as a result of a breach. How much depends on the business – imagine an ecommerce store being down for hours or days due to a breach.
Loss of customer trust
Customers are more cautious about their data and where it is shared. Losing customers’ data due to a cybersecurity breach can be devastating both to the brand image and customer trust. Loss of customers’ data can in some cases even lead to a shutdown of the business.
Compliance and penalties
Governments are imposing security standards such as GDPR, HIPAA, PCI and ISO 27001 to make sure companies don’t get away with neglecting security. Having your company not comply with those standards can result in fines, penalties or lawsuits.
In this article, we’ll cover the following web application security best practices:
One of the best ways to ensure there are no security loopholes in your web applications is to have regular security audits.
A security audit can include one or more of the following:
Black box security audit: this is the ‘hacker approach’. The application is tested for exploitable vulnerabilities without access to the source code.
White box security audit: opposite to black box security audits, in a white box security audit you or the team performing the audit have access to information including the code base. This type of a security audit ensures you are following all the best practices, starting with secure coding practices.
Grey box security audit: as the name suggests, this is a mix approach of white box and black box security audits. In this approach some important information is shared before the audit.
If there are any vulnerabilities detected after your audit, the best approach is to categorise them by their impact, prioritise their remediation and start fixing them with the highest impact vulnerabilities first (Critical / High).
2. Encrypt data
Visitors and customers could share sensitive information on your website. The data in transit between the visitor’s browser and your server has to be encrypted.
Encrypting the data in transit does not only help with customer trust, but also plays an important role in SEO ranking. Search engines like Google prefer websites with SSL. The use of HTTPS is even a ranking factor for Google.
However, it’s not only the data in transport that has to be encrypted. You also have to encrypt the data in rest to make sure malicious actors can’t just copy or destroy it. Follow these practices to make sure your data is secure:
Implement network firewalls. That will help prevent threats from within the network
Chose a strong encryption algorithm and encrypt the data before you store it
Store data on a separate server in a password-protected database
Infrastructure security is important. Don’t neglect it and invest in infrastructure security
3. Real time security monitoring
We already mentioned the importance of regular security audits, but those will not be enough without a robust real time monitoring. Consider using a web application firewall (WAF) which will help you block any malicious activity in real time.
As web application firewalls can indicate false positive events or miss some threats, consider using ASMP or RASP in addition.
An Application Security Management Platform (ASMP) monitors protocols beyond the application layer and helps you protect your apps against unknown threats in real time. While ASMP is embedded into your app, RASP runs on your server and monitors the behavior of your web applications and context of user input. If RASP detects suspicious activity, it will immediately terminate the session and block the malicious user. Please keep in mind that neither of those guarantees 100% success.
4. Proper logging practices
To have a good insight into events in your app, like what happened at white time, was there something else happening at the same time and how that affected a situation that occurred, you need to have proper logging in place. While this is important information to continually have and monitor, it’s especially important in case of a security incident.
Post-incident forensics can become a daunting task without proper logging in place. On the other hand, with a proper logging mechanism, the task of analysing the cause and understanding the bad actor in case of a data breach becomes much easier.
5. Implement security hardening measures
Default settings won’t be enough for some components and will need security hardening measures, such as:
Maximum script execution time: Set the maximum time a particular script can run on the server. A low number here could help narrow the attack possibilities. Define the maximum script execution time by your application’s use case.
Disable modules: Are there modules and extensions on your server that are not in use by the application? Disable them.
Have a content security policy in place: a good content security policy can help prevent infections like redirection malwares from taking over.
6. Regular vulnerability scans and updates
Hackers are quick when it comes to identifying websites running vulnerable software. Be one step ahead of them by running regular vulnerability scans and identifying vulnerabilities in your web applications or websites before they hit production. This is achieved by implementing automated security testing into your CI/CD pipelines. SAST tools are traditionally implemented earlier into the SDLC, but the results are high in false positives, while requiring a more complex configuration and access to your source code. On the other hand, while traditional DAST tools are language agnostic (they don’t need access to the source code), they are typically used by security professionals and implemented later into the SDLC or used on production.
Unlike other security testing tools, Bright is built from the ground-up to be developer first, integrated across your pipelines to scan every build / commit as part of your CICD to be secure by design. Easy to use and intuitive, you don’t have to be a security expert to start a scan. With NO false positives, Bright automatically validates every finding so you don’t have to. Thanks to the integration with various ticketing systems, all findings can be easily assigned to different team members for remediation, with developer friendly remediation guidelines for immediate and easy fix at the cheapest, most efficient time.
Sign up for free and see for yourself why Bright is a platform that security teams trust and developers love.
