What is API Security?

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.

Related content: Read our guide to ws security.

This is part of an extensive series of guides about application security

In this article, you will learn:

• Why Is API Security Important?
• How is API Security Different from General Application Security?
• REST API Security vs. SOAP Security
• GraphQL Security
• Methods Of API Security Testing
• Top Open Source API Testing Tools
• API Security Best Practices

Why Is API Security Important?

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.

Learn more about SOAP security

GraphQL Security

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:

https://vulnerablesite.com/view?name=userfile.txt;restart

Test for API Input Fuzzing

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.

Learn more in our detailed guide to rest api testing

Top Open Source API Testing Tools

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

Learn more in our detailed guide to api security testing tools

API Security Best Practices

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.

Related content: Read our guide to api security best practices

Adopt a Zero-trust Philosophy

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

Learn more about Bright

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.

Vulnerability Management

Authored by Bright Security

• Vulnerability Management: Lifecycle, Tools, and Best Practices
• Vulnerability Examples: Common Types and 5 Real World Examples
• Vulnerability Testing: Methods, Tools, and 10 Best Practices

CSRF

Authored by Bright Security

• Cross-Site Request Forgery (CSRF): Impact, Examples, and Prevention
• CSRF tokens: What is a CSRF token and how does it work?
• Open Redirect Vulnerability: Impact, Severity, and Prevention

LFI

Authored by Bright Security

• Local File Inclusion: Understanding and Preventing Attacks
• File Inclusion Vulnerabilities: What are they and how do they work?
• LFI Attack: Real Life Attacks and Attack Examples

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

• 1. Automate
• 2. Check Code dependencies
• 3. One step at a time
• 4. Pick your tools carefully
• 5. Threat modeling
• 6. Secure coding training

Bonus: What makes Bright the perfect tool for DevSecOps

1. Automate

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. 

Learn more in our detailed guide to devsecops tools.

5. Threat modeling

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.

Learn more in our detailed guide to devsecops vs devops.

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

Start automating your security testing in your pipeline – sign up for a free Bright account and try it yourself.  

Table of Content

1. What Is Penetration Testing?
2. Network Penetration Testing
3. Web Application Penetration Testing
4. Wireless Penetration Testing
5. Physical Penetration Testing
6. Social Engineering Penetration Testing
7. Client-Side Penetration Testing
8. IoT Penetration Testing
9. Mobile App Penetration Testing
10. Red Team Penetration Testing
11. How to Choose the Right Penetration Testing Type
12. Penetration Testing vs Vulnerability Scanning: What’s the Difference?
13. Common Penetration Testing Tools by Type
14. Reporting Best Practices After Penetration Tests
15. Complementing Penetration Testing with Dynamic Application Security Testing (DAST)

What Is Penetration Testing?

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:

• Firewall misconfiguration and firewall bypass
• IPS/IDS evasion
• Router attacks
• DNS-level attacks
• Zone transfer attacks
• Switching or routing-based attacks
• SSH attacks
• Proxy server attacks
• Attacks on unnecessary open ports
• Database attacks
• Man-in-the-middle (MitM) attacks
• FTP/SMTP-based attacks
• Complementing Penetration Testing with Dynamic Application Security Testing (DAST)

2. Web Application Penetration Testing

Web application penetration testing is used to find vulnerabilities in web-based applications. It uses a three-step process: 

1. Reconnaissance—discovering information about web servers, operating systems, services, resources, and more used by the web application
2. Discovery—finding vulnerabilities in the web applications and planning attack vectors to be used in the penetration test.
3. 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.

Related content: Read our guide to web application penetration testing

3. Wireless Penetration Testing

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. 

Related content: Read our guide to penetration testing services

How to Choose the Right Penetration Testing Type

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. 

Learn more about the Bright Security DAST 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.

In this article:

• Network Security Threats and Attacks
  • Malware
  • Phishing
  • DDoS Attacks
  • Advanced Persistent Threats (APTs)
  • Drive-by Downloads
  • DNS Attack
• External vs. Internal Network Penetration Testing
  • External Penetration Testing
  • Internal Penetration Testing
• Network Penetration Testing Process
  • Reconnaissance
  • Discovery
  • Exploitation
  • Analysis
• Network Penetration Testing with Bright

Network Security Threats and Attacks

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

Related content: Read our guide to penetration testing services

Network Penetration Testing Process

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.

Related content: Read our guide to penetration testing report

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. 

Learn more about automated network testing with Bright Security

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.

In this article:

• Why is Web Security Testing Important?
• Top Web Application Security Risks
  • Injection
  • Denial of Service (DoS) and Distributed Denial-of-Service (DDoS)
  • Cross-site Request Forgery (CSRF)
  • Cross-Site Scripting (XSS)
  • Security Misconfiguration
  • XML External Entities (XXE)
  • Vulnerable Deserialization
• Tools You Can Use to Defend Against Web Application Threats
• 6 Web Application Security Best Practices
• Securing Web Applications with Bright Security

Why is Web Security Testing Important?

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.

Learn more in our detailed guide to web application security testing.

Top Web Application Security Risks 

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.

Learn more in our detailed guides to:

• Code injection
• 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.

Related content: Read our guide to security testing tools.

Cross-site Request Forgery (CSRF)

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.

Related content: Read our guide to web application attacks.

Cross-Site Scripting (XSS) 

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.

Learn more in our detailed guide to web application vulnerabilities.

Security Misconfiguration

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.

Learn more in our detailed guide to websocket security.

XML External Entities (XXE) 

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.

Learn more in our detailed guide to XXE

Vulnerable Deserialization

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.

Learn more in our detailed guide to deserialization

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:

1. 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
2. Software composition analysis (SCA)—involves analyzing applications to identify open source software (OSS) and third-party components containing known vulnerabilities or licensing restrictions. 
3. 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. 
4. 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:

5. 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. 
6. 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. 

Related content: Read our guide to microservices security.

6 Web Application Security Best Practices

1. Execute Input Validation

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.

Related content: Read our guide to web application attacks.

2. Employ Up-to-Date Encryption

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.

Learn more in our detailed guide to web application scanning.

4. Track API Usage

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.

Related content: Read our guide to websocket security.

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. 

Learn more in our detailed guide to mobile security.

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.

API Security

Authored by Radware

•  API Security: REST vs. SOAP vs. GraphQL & 8 Best Practices 
•  Server-Side Request Forgery: Impact, Examples & Defenses 
•  API attack 

disaster recovery

Authored by Cloudian

• What Is Disaster Recovery? – Features and Best Practices
• What Is BCDR? Business Continuity and Disaster Recovery Guide
• Disaster Recovery Plan: 4 Examples & 10 Things You Must Include

XSS

Authored by Bright Security

• What is XSS? Impact, Types, and Prevention
• Reflected XSS: Examples, Testing, and Prevention
• How DOM Based XSS Attacks work

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:

1. Full-scale security audit
2. Encrypt data
3. Real time security monitoring
4. Proper logging practices
5. Implement security hardening measures
6. Regular vulnerability scans and updates

1. Full-scale security audit

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.

What Is AWS Penetration Testing?

Penetration testing typically involves an ethical hacker looking for network vulnerabilities that a malicious hacker could exploit. These tests provide insights into a network’s points of weakness, informing security teams on how to repair them.

However, Amazon Web Services (AWS) doesn’t always support standard ethical hacking practices, because they may conflict with Amazon policies. Amazon owns the core infrastructure of AWS, so any penetration testing methodologies used on AWS systems are subject to Amazon’s policies.

Pentesting in AWS generally has to address these main areas:

• The external AWS cloud infrastructure 
• The internal AWS cloud infrastructure
• Any applications built or hosted on the platform
• Review of the AWS configuration

In this article:

• The Importance of AWS Pentesting
• Penetration Testing Methodologies for AWS
• AWS Vulnerabilities and Pentest Tools
• Complementing Penetration Testing with DAST

The Importance of AWS Pentesting

As AWS continues to deploy more services and serve millions of additional users, the system becomes exponentially more complex. This added complexity could allow attackers to exploit undiscovered vulnerabilities. The problem only increases if the human factor is also taken into account—any user or administrator who has an identity and access management (IAM) account can be the target of a social engineering attack.

Regular AWS penetration testing is critical for cybersecurity professionals to address these challenges. Penetration testing can help discover misconfigured security groups and excessive privileges, known vulnerabilities in cloud systems, misunderstandings regarding the shared responsibility model which can lead to unintentional risk exposure, failure to implement strong authentication for cloud resources, and lack of employee education with regard to social engineering.

Another aspect of penetration testing is that it can help achieve compliance with regulations such as HIPAA, PCI DSS, and FedRAMP. These and other compliance standards require regular penetration testing to identify, address, and remediate compliance gaps.

Amazon supports penetration testing against its systems, but requires special approval for certain types of tests. Organizations should rely on security experts with the expertise to perform Amazon penetration testing. AWS security partners know what to test and which simulations require Amazon approval.

Penetration Testing Methodologies for AWS

The security testing methodologies of an AWS platform fall into these two categories:

• Security of the cloud—Amazon is responsible for ensuring that the AWS cloud infrastructure is secure. This category includes any vulnerabilities, logic flaws, or zero-day threats on AWS servers that may impact their performance or damage users.
• Security in the cloud—the customers are responsible for ensuring that the assets and applications they deploy on the AWS platform are secure. Organizations must follow the required security procedures to enhance the security of their applications in the AWS cloud.

AWS allows security testing for user-operated services, including cloud offerings that the user creates and configures. Organizations can test their AWS EC2 instances, for example, without incorporating tactics that might disrupt business continuity (e.g., launching a DoS attack).

AWS restricted security testing for vendor-operated services, including any cloud offering that a third-party vendor owns or manages. AWS allows users to pentest the cloud environment configuration and implementation, but not the hosting infrastructure. For example, customers can perform penetration tests for the configuration of AWS services like API Gateway and Cloudfront, but they can’t touch the underlying infrastructure.

One AWS service that supports penetration testing is Elastic Cloud Computing (EC2). The following areas of AWS EC2 instances are open to pentesting:

• The API 
• Customer-hosted mobile and web applications
• The application server 
• The stack associated with an application 
• Virtual machines (VMs) 
• Operating systems

Organizations traditionally use pentesting in on-premise environments or infrastructure-as-a-service (IaaS) offerings. AWS has many software-as-a-service (SaaS) offerings that don’t allow the customer to perform penetration tests because Amazon owns the environment. However, customers can use a black box or security audit to test the identity and configuration of a SaaS service. 

Other areas of the AWS cloud that don’t allow pentesting for legal or technological reasons include:

• Applications and services owned by AWS (including SaaS offerings)
• Third-party EC2 environments owned by another vendor or partner
• Any underlying infrastructure or physical hardware owned by AWS
• Micro or small AWS Relational Database Service (RDS)
• Third-party security appliances managed by another vendor (unless the customer has permission)

AWS Vulnerabilities and Pentest Tools

Several vulnerabilities specifically affect AWS systems, although some are more common than others. Some of the top vulnerabilities of the AWS architecture include:

•   Permissions and configuration flaws—for example, in S3 bucket policies.
•   Compromised credentials—for example, identity access management (IAM) keys.
•   Cloudfront or WAF misconfigurations—enable attackers to bypass security measures.
•   Lambda backdoor functions—enable private cloud access.
•   Cloudtrail log obfuscation—covers an attacker’s tracks. 

It is important to understand the approach and capabilities of a pentest provider. Choosing the right provider allows organizations to leverage end deliverables to identify and prioritize business risks so their teams can take action. 

Related content: Read our guide to penetration testing services

Many independent and off-the-shelf tools are uniquely developed for cloud environments and help organizations understand AWS flaws and misconfigurations. Basic tools for identifying basic vulnerabilities include:

The following basic tools can also help identify basic flaws:

• AWS Inspector—designed to secure applications deployed on AWS.
• BucketHead—from Rhino Security Lab, identifies misconfigured S3 Buckets.
• Nmap—discovers networks and enumerates services.

Basic tests using free tools can be a good start for addressing low-hanging fruit, but they don’t provide extensive protection against vulnerabilities and other business risks. Third-party security providers can offer the expertise and experience necessary to conduct comprehensive AWS security assessments and strengthen an organization’s security posture.

Related content: Read our guide to penetration testing tools 

Complementing Penetration Testing with Dynamic Application Security Testing (DAST)

Penetration testing is valuable to ensure your applications and network are secure, however a large proportion of each is conducted manually by specialist penetration testers. The penetration process takes time, is not scalable and the costs can spiral.

With more companies now apopting DevOps and CICD, further automation of security testing is required that removes security related bottlenecks and provides a direct and immediate feedback loop to developers.

Bright Security’s developer focused Dynamic Application Security Testing scanner is used by penetration testing companies to carry out preliminary scans on their client applications and APIs. You can integrate Bright into your development pipelines to benefit from continual, scalable security testing early and often, on every build / commit. 

Bright automatically validates every security issue, so has NO false positives. This removes the need for you to manually validate security issues (one of the services performed by PT / PTaaS). Coupled with the ability to detect Business Logic Vulnerabilities with Bright, this reduces your reliance on and cost of your manual penetration testing or PTaaS.

Sign up for a FREE Bright account and start automating your application and API security testing

Table of Content

1. What is SQL Injection and Can it Happen in an Oracle Database?
2. Examples of SQL Injection in Oracle
3. How to Prevent SQL Injection in Oracle
4. Detecting SQL Injection in Oracle
5. Conclusion

What is SQL Injection and Can it Happen in an Oracle Database?

Unfortunately, the quick answer is a resounding YES – Oracle databases are by no means immune to these attacks.

SQL injections represent one of the most prominent and dangerous attacks, a staple inclusion in the OWASP Top 10. It is a code injection technique used to exploit vulnerabilities in the application layer to retrieve or corrupt the data they hold. 

One example is when a required user’s input is either incorrectly filtered, or the user’s input is not strongly typed and unexpectedly executed or the user gives an SQL statement instead.

While SQL injections are known predominantly as a website attack vector, they are also used to attack any SQL database. 

Security of your applications that use Oracle databases is imperative to secure your data and reputation, especially as attackers have multiple automated tools at their fingertips to facilitate an SQL attack.  Below are some tips on how to protect your web apps.

Using MongoDB…? Read more about SQL injection in MongoDB 

Examples of SQL Injection in Oracle

Attackers carrying out SQL injection attacks in Oracle will generally try to minimize the number of database calls in order to maximize their chances of success. 

One of the most popular tools used to carry out SQL injection in Oracle is an open-source tool called BSQL Hacker, used to discover exploits in the target web application. Some of the things that BSQL Hacker does include:

• fingerprint database version, user details, and permission
• changing attacker’s permissions to database admin
• obtaining available data from the database

One of the safest ways to defend from SQL Injection is to never, ever concatenate user input into your SQL queries. These inputs should always – and by always we mean without exception – be bound into the statement. As soon as you allow the end-user to input the code into your SQL statements, it’s as if you gave them the key to your apps. To carry out an SQL injection attack, an attacker must first find vulnerable user inputs within the web page or application and then input content, namely malicious SQL commands, which are in turn executed in the database. Successful attacks can gain total control over the affected database.

Although they have devastating repercussions and widespread awareness, SQL injections remain commonplace, with most web applications remaining vulnerable in production.

It is crucial to understand how to prevent SQL injection attacks and hackers from breaching your databases.

How to Prevent SQL Injection in Oracle

SQL injection can be prevented using proper programming techniques and robust testing as part of your development pipeline. Here are some tips that could help you to prevent SQL injection in Oracle and keep your application protected:

1. Input Validation 

You must take precautionary measures in order to ensure that the attacker cannot inject malicious code via forms that go out directly towards the database. This is the most common issue as the developers are unaware of the fact that loose input validation could result in catastrophic consequences. What you should at least do is limit the number of characters a user can send into a form field. So, in case you have a “first name” field, it should never contain more than 32 characters. 

2. Minimum Permissions 

Another useful tip is to only grant minimum permissions possible to the end user. This means limiting their ability to edit content on your website as much as you can, because it ultimately means that you’re protected from the attacker potentially taking over as an admin on your website. 

3. Static Statements

What you should also be doing when writing queries and such is to try to always use static statements, where the attacker cannot inject dynamic content that changes your website. As an additional step in securing your web application, make sure that you’re binding variables whenever you can, given that it provides an extra layer of security. 

4. Encrypt Confidential Data

Encrypting the most important and confidential data makes sure that you add an extra layer of protection that might just make a key difference for your web app. Thus, you ought to do this whenever possible since it’s the most popular protection method ever since security took its place in modern IT.

5. Blacklisting

This one is pretty simple, yet extremely efficient in preventing malicious codes from entering your web apps. You can create a list of characters that a user cannot send via input forms, such as “<>/?*()&”, or even malicious statements like “SELECT”, which is automatically limiting the scope of vulnerability on your website. 

Detecting SQL Injection in Oracle

Securing your applications is crucial nowadays. The data has never been more important and sensitive, which also means that the attackers are getting smarter by the day. 

This is why Bright Security’s developer-focused approach allows for non-security-minded developers to scan their applications and find all about potential vulnerabilities. In fact, you can sign up for a free account now in order to scan your applications and ensure that you avoid SQL injection and all other sorts of attacks on your apps. 

Conclusion

Hopefully this article sheds some light on the threat of SQL injection in your Oracle database. Security of your applications should never be taken for granted, which is why checking and testing for security is now a part of our everyday work as developers.

What is Cross Site Request Forgery (CSRF)?

A CSRF attack can force a user to perform unwanted actions on a web application. CSRF assumes that the user is already authenticated. Attackers typically use social engineering to trick users into clicking a link that performs actions that can benefit the attacker.

For example, on an eCommerce website, the attacker can cause the user to inadvertently make a purchase. On a bank website, the attacker can cause the user to transfer funds. If the user has administrative access to a web application, CSRF can be used to compromise the entire application.

In this article:

• How CSRF Attacks Work
• 6 CSRF Protection Best Practices
  • 1. Same-Site Cookies
  • 2. CSRF Tokens
  • 3. Addition Authentication for Sensitive Actions
  • 4. Login CSRF
  • 5. Representational State Transfer (REST)
  • 6. Web Application Security Testing
• CSRF Protection with Bright

How CSRF Attacks Work

A website consists of client-side code, typically written in HTML and JavaScript, and server-side code, which depends on the framework used to build the website. Client-side code allows users to perform actions like navigating to different URLs, submitting HTML forms, and triggering AJAX requests via JavaScript. The server-side code intercepts the data sent in the HTTP request and handles it appropriately.

These server-side actions can also be triggered by forged HTTP requests, unless you explicitly protect them. CSRF attacks occur when a malicious attacker tricks the victim into clicking on a link or executing code that triggers a forged request. The malicious code is hosted on another domain controlled by the attacker, therefore the attack is known as “cross site” request forgery.

To protect yourself from CSRF, you need to do two things. Make sure your GET requests have no side effects, and only allow non-GET requests from your client code.

6 CSRF Protection Best Practices

1. Use Same-Site Cookies

CSRF attacks are only viable because cookies are sent with any requests sent to an origin related to that cookie. You can create a flag for a cookie, which converts it into a same-site cookie. 

Threat actors can send a same-site cookie only if a user made a request from the cookie’s origin. However, it is not possible when a request is made across domains. The request source and the cookie have the same origin if the following conditions are met:

• They have the same protocol and host, but they do not share the same IP address.
• When applicable, they can also share the same port. 

Not all browsers support same-site cookies (see a full compatibility chart), and a same-site cookie will default to a regular cookie when a visitor uses an older browser. It means same-site cookies are more suited as an added layer of defense, and you should only use them with other CSRF security mechanisms. 

2. Use CSRF Tokens

A popular approach to stop CSRF is using a challenge token. A challenge token is connected with a specific user and is sent as a concealed value in all state-changing forms via the web application. This token is an anti-CSRF token, also known as a synchronizer token.

Here is how the anti-CSRF token works:  

• The web server creates a token and retains it
• The token is statically created as a concealed field of the form 
• The user submits the form
• The token is a part of the POST request information
• The application compares the token created and stored by the application with the token transferred in the request
• If these tokens are the same, the request is validated
• If these tokens are different, the request is rejected 

This CSRF protection approach is known as the synchronizer token pattern. It secures the form from CSRF attacks because a cybercriminal also has to guess the token to trick a target into creating a valid request. Attackers cannot readily guess the token, and they cannot create it according to a predictable pattern. To improve protection, invalidate the token after a timeout period, or every time the user logs out. 

Anti-CSRF tokens are typically exposed via AJAX – they are sent as request parameters or headers alongside AJAX requests. To be successful, an anti-CSRF mechanism must be cryptographically protected. 

It is also recommended to utilize anti-CSRF options in development frameworks, rather than having developers create their own mechanisms. This reduces mistakes, makes implementation smoother, and in the end improves security. 

3. Require Stronger Authentication for Sensitive Actions

Many websites require a secondary authentication measure or need reconfirmation of login details when a user carries out a sensitive action – for example, on a password reset page. Generally, the user needs to enter their old password before they create a new password.  

This approach protects the user who could remain logged in by accident and minimizes the likelihood of CSRF attacks. 

4. Mitigate Login CSRF

CSRF vulnerabilities can occur on login forms even when users are not logged in. For example, an attacker could employ CSRF to adopt an authenticated identity of the target on an eCommerce site using the attacker’s account. If the victim then enters their credit card details, an attacker could purchase items via the target’s stored credentials. 

You can mitigate login CSRF by establishing pre-sessions that include tokens in the login form.  You can use a pre-session only before a user is verified – do not reuse it after the user is authenticated. Instead, you should destroy the session and create a new one to avoid session fixation attacks. 

If you do not trust subdomains within your master domain in your threat model, it is challenging to mitigate login CSRF. In this case, you can use strict subdomain and path level referrer header verification to mitigate CSRF on login forms.

5. Use Representational State Transfer (REST) Principles

Representational State Transfer (REST) is a set of design principles that assign actions (create, view, update, delete) to various HTTP verbs. Using REST-ful designs helps your site scale and keeps your code clean. REST demands that GET requests are only utilized for viewing resources. 

Maintaining your GET requests side-effect-free will minimize the damage that maliciously created URLs can achieve. Consequently, an attacker has to work harder to create damaging POST requests. 

6. Leverage Web Application Security Testing

After you have effectively resolved a vulnerability in a web application that could enable a CSRF attack, vulnerabilities can still occur later on. These vulnerabilities occur because developers update the application and change its code. 

Given this, it is recommended that you continually test and scan your web applications for any vulnerabilities, including those connected with CSRF attacks. You should use web applications security tools. 

CSRF Protection with Bright Security

Bright helps you automate the detection and remediation of many vulnerabilities including CSRF 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 hit production. Bright completes scans in minutes and achieves zero false positives, by automatically validating every finding. This allows developers to adopt the solution and use it throughout the development lifecycle.