The UK’s planned overhaul of legislation designed to protect critical national infrastructure (CNI) will apply to a wider range of sectors and introduce tough new incident reporting requirements.

These measures accord with a promise to align the Cyber Security and Resilience Bill, “where appropriate”, with the EU’s NIS 2 regulation, made in a 

 issued by the Department for Science, Innovation & Technology (DSIT) on 1 April.

 (PDF) in July 2024 shortly after the Labour government entered office, will supersede the EU’s Network and Information Systems (NIS) Regulations 2018. Although the 2018 NIS regulation was 

, the first NIS framework has continued to apply in the UK due to the country’s departure from the trading bloc in 2020.

The policy statement for the bill says it will draw on “insights we have gathered from our international partners, including valuable lessons from the European Union on the implementation of its NIS2 regime”.

The bill “will address the specific cyber security challenges faced by the UK while aligning, where appropriate, with the approach taken in the EU NIS 2 directive”. With Prime Minister Keir Starmer having declared growth his defining mission, the policy statement adds that “this strategic approach ensures we can be flexible and responsive to cyber threats in a proportionate way that balances the impact on business”.

Data centres, managed service providers in scope

Incident reporting obligations will, in alignment with NIS 2, require in-scope entities to notify relevant authorities of significant security incidents within 24 hours, and then submit a more detailed report within 72 hours.

Also mirroring NIS 2, the bill will bring managed service providers (MSPs) into scope, with the policy statement noting their “unprecedented access to clients’ IT systems, networks, infrastructure and data”.

 in September 2024, will also be in scope. Those above a certain capacity threshold will have to share information with authorities, and comply with obligations around risk management and “reporting significant incidents”.

Supply chain security will also become a focus of UK cyber law – another similarity to NIS 2 – through the mechanism of secondary legislation that will introduce new duties for operators of essential services (OES’) and relevant digital service providers (RDSPs). These duties will include “appropriate and proportionate measures [...] to prevent vulnerabilities in suppliers from undermining essential or digital services”. 

Regulators will also be empowered to “designate specific high-impact suppliers as ‘designated critical suppliers’ (DCS)”, which will be subject to “core security requirements and incident reporting obligations”.

Recognising the fast-evolving nature of cyber threats, the legislation will grant the DSIT Secretary of State powers to rapidly update regulations without needing fresh primary legislation.

While the policy statement repeatedly hints at less onerous business-friendly regulations, the need to minimise compliance burdens and facilitate cross-border cooperation and information-sharing will surely ensure a high degree of alignment with NIS 2.

NIS 2 has broadened the range of in-scope sectors

, divided them into “essential” and “important” categories, strengthened information-sharing measures, and introduced various measures for facilitating coordinated vulnerability disclosure (CVD).

To find out how YesWeHack can help you comply with UK and European cyber regulations, 

 of our Bug Bounty, vulnerability management and attack surface management platform.

UK publishes proposals for NIS 2-equivalent Cyber Security and Resilience Bill

Did you know that manipulating a single HTTP header can unlock high-impact security flaws hidden within a web application?

HTTP headers control how browsers and servers interact with data, so these vulnerabilities can affect the entire application stack.

In this comprehensive guide, we share techniques – both simple and advanced – for exploiting vulnerabilities in HTTP headers, ranging from abusing custom headers to leveraging cache poisoning and reverse proxy misconfigurations.

With real-world examples and easy-to-follow tips, this article will help you spot weaknesses faster and boost your Bug Bounty and ethical hacking skills.

Let's dive in and uncover how minor modifications to request headers can reveal major security issues!

CPDoS via Akamai: caching error responses

CPDoS on Cloudflare: infinite redirect loop

Common HTTP headers used by reverse proxies

General HTTP headers used by reverse proxies

Mitigation & best practices for HTTP header exploitation

Analysing HTTP response headers provides valuable information about the web application. Headers can reveal running services, software versions, and programming languages employed by the application. Such details help in tailoring payloads and selecting appropriate attack methods for further testing or direct HTTP header exploitation.

Inspecting custom HTTP headers in both responses and requests is a valuable first step when scanning a target. Customised headers often reveal sensitive information – such as internal system information or framework identifiers – or inadvertently expose pieces of code that can be leveraged for further reconnaissance.

An attacker can harness custom headers as keywords for open source intelligence (

) recon, potentially uncovering source code leaks and other technical information related to the application.

' responses, as they often expose headers that are not typically visible in server responses. These error responses often include default configurations as well as internal debugging information and naming conventions:

 can potentially retrieve fragments of source code that handle custom headers. For instance, source code in Github repos sometimes includes elements that interact with custom headers. So if you identified the header ‘X-Internal-Token: secret-value’, you could use Google to search (ie, dork) "X-Internal-Token" site:github.com”, which might then reveal hardcoded references in backend code, sample configs or .env files, or middleware or route handlers checking for the header.

 specifies which parts of the request message should be considered when creating a cache key. This mitigates attacks such as 

, where an attacker manipulates the cache to serve malicious content to other users.

 header values indicate whether a given user input is being trusted or reflected by the application. This may signal a potential attack surface for further testing.

As you can see above, the response contains the 

. Let’s leverage this information to test if the web application trusts user input:


Sure enough, the response confirmed that the 

 header is being reflected in the HTML and is likely being trusted by the application.

This discovery paves the way to using the 

 header to check for unexpected behaviours. Techniques such as 

 can potentially lead to cache poisoning. It might be possible to poison the cache if some responses use 

, the following setup can be combined with dictionary or brute-force attacks to extract hidden headers from the target:

Keep in mind that header-based fuzzing can sometimes produce 

 (CDN) and/or backend only respond differently under specific header configurations.

For example, a basic request using a simple Forwarded header may result in a normal response:

 header configuration does not work either, alternative configurations are available for testing against the application (see the 

In the example above, the forwarded header 

for=example.com;host=example.com;proto=https

. This allowed us to further experiment with the header’s value to determine the cause of the error, and later discover a

cache poisoning vulnerability affecting the application.

) is achieved when an attacker caches a malicious or malformed response that causes the legitimate page content to become inaccessible. Once stored in the cache, the poisoned response is served to all users attempting to access the affected resource – effectively resulting in a denial of service.

Let’s examine a real-world scenario where the cache error responses feature is enabled. By default, 

 edge servers cache error responses with status codes 

 for 10 seconds. However, this behaviour can extend to other status codes, depending on system configuration. 

If an attacker sends an invalid header – for example 

 – the server will typically return a 400 Bad Request error: 

When the cache error responses feature is enabled, this error response may be cached, resulting in CPDoS for other users regardless of whether their request is legitimate or not.

 caches certain HTTP response codes (200, 206, 301, 302, 303, 404, 410) with the Edge Cache TTL, unless overridden by Cache-Control or Expires headers. 

Cloudflare also uses the header X-Forwarded-Proto

 to determine the client's protocol version (HTTP vs HTTPS).

If a cached redirect accepts this header, it becomes possible to set the X-Forwarded-Proto header value to http. When the target detects this value, it attempts to redirect to the https version.

However, since our request was made using https, this manipulation causes Cloudflare to mistakenly interpret the request as http, resulting in a redirection back to https. This misconfiguration triggers an infinite redirect loop that eventually leads to a crash once the maximum number of redirects is reached. Given that Cloudflare typically caches 301, 302 and 303 responses, this attack method is frequently observed in web applications that utilise Cloudflare’s CDN.

Then on an HTTPS request, the backend may attempt to redirect to HTTPS again, causing an infinite redirect loop:

Because the redirect is cached, every user hitting that route may be trapped in a loop - eventually resulting in a browser error after too many redirects.

 cookie to differentiate between human and bot traffic. Automated tools are typically blocked quickly. However, misconfigured implementations can be vulnerable to the 

If an attacker supplies the misconfigured 

 cookie with a random or null value, the attacker could evade rate limits and potentially gain access to authenticated endpoints. I contacted 

 to confirm this behaviour and received the following response:

For those interested in bypassing techniques, I recommend reading our 

 article, which details advanced methods for circumventing firewall and filter protections in web applications.

Modern web architectures often implement several caching layers managed by different teams, and expose multiple cache headers in their HTTP responses. When caching is configured inconsistently, security vulnerabilities can arise through cache header collisions and inconsistent normalisation.

In the example below, a Drupal-based system uses two caching headers: 

 (proxy or VPN-level cache). When the page is successfully cached, these headers display a status of HIT; if not, they display MISS.

, confirming that the page had been cached, although the 

 header to our request, both headers were confirmed as cached (HIT), while the 

HTTP header hacks: basic and advanced exploit techniques explored

A voluntary code of practice designed to tackle the proliferation and irresponsible use of surveillance tech has so far been adopted by 22 states.

 (PDF) provides a framework for regulating the development, distribution, purchase and use of tools with commercial cyber intrusion capabilities (CCICs) – more commonly known as spyware.

Emerging from the ‘Pall Mall Process’, a British-French initiative 

, the accord was adopted at a conference in Paris last week. YesWeHack’s CEO and co-founder, Guillaume Vassault-Houlière, attended the event, as well as workshops held last year to discuss the proposals, to advocate for the robust protection of good-faith use of CCICs for security research purposes.

The Paris conference, which took place on 3 and 4 April, 

brought together 39 states, four international organisations

 and a broad coalition of representatives from civil society and the private sector, including the cybersecurity industry.

“Without international and meaningful multi-stakeholder action, the growth, diversification, and insufficient oversight across this market raises the likelihood of increased irresponsible targeting of a range of public and private targets, including journalists, human rights defenders and government officials, as well as critical national infrastructure,” reads the code of practice. “It also risks facilitating the spread of potentially destructive or disruptive cyber capabilities to a wider range of actors, including cyber criminals.”

Signatory states have volunteered to, among other measures, establish processes for banning CCIC vendors that engage in irresponsible behaviour, encourage CCIC vendors to prevent and mitigate the adverse human rights impact of CCICs, and consider human rights impacts when making export control licensing decisions.

However, the code of practice balances concerns about the risks posed by malicious use of these tools with an acknowledgement that their legitimate use must be protected. CCICs are used by security researchers, including in 

, in ways that – perhaps counterintuitively to those unfamiliar with ethical hacking – can help 

Mindful of this, the code of practice urges governments to establish or define “clear national policies on what constitutes legitimate use of CCICs in the context of cybersecurity (for example for penetration testing, red teaming and in relation to coordinated vulnerability disclosure policies and bug bounty programmes) and research for cybersecurity activities, aligned to existing protections or safeguards for cybersecurity researchers.”

Governments are also advised to encourage “commercial entities to establish and publish their own coordinated vulnerability disclosure processes, informed by existing international standards”.

The accord’s recommendations fall into four core pillars:

, such as applying export controls to prevent misuse and supporting victims of malicious use

, to clearly define lawful use of these tools, such as for national defence, cybersecurity or law enforcement; to coordinate internally across government bodies; and to train cybersecurity professionals to ensure responsible use and reporting

, to implementmechanisms that ensure state activities involving CCICs are transparent and subject to review

, includinginformation sharing among states, industry and civil society; establishing coordinated vulnerability disclosure practices; and implementing ‘Know Your Vendor/Customer’ requirements

Far from concluding the Pall Mall Process, the voluntary accord apparently represents a milestone in ongoing efforts to keep abreast of evolving and emerging threats – not least the threat of artificial intelligence supercharging the capabilities of CCICs.

“We intend to regularly review progress on the implementation of these voluntary good practices and on improving accountability across the market,” the code reads. “We resolve to keep this Code of Practice up to date with developments in the threat landscape.”

Signatories to the accord include: Austria, Denmark, Estonia, France, Germany, Ghana, Greece, Hungary, Ireland, Italy, Japan, Kosovo, Luxembourg, Moldova, Netherlands, Poland, Romania, Slovakia, Slovenia, Sweden, Switzerland and the United Kingdom.

 voluntary agreement over the same issue was signed in 2023 by 11 countries.

Persuading a wide range of nations to attend such conferences, let alone agree to common policies and enforcement mechanisms, is not easy. Spyware offers valuable intelligence capabilities – whether for national security or tackling terror threats – that some governments are reluctant to surrender. More than 80 countries have purchased spyware over the past decade, Britain’s intelligence agency

Spyware pact draws distinction between malicious and legitimate use of cyber-intrusion tools

GraphQL is an increasingly popular alternative to REST APIs, but its greater versatility also offers rich hacking opportunities.

For instance, the greater complexity of this query language creates scope for vulnerabilities with significant potential to expose significant volumes of sensitive data.

Moreover, popular use cases – such as mobile, SaaS and ecommerce applications as well as rapidly evolving software – mean that the organisations leveraging GraphQL sometimes have relatively significant financial resources.

Taken together, these observations mean that GraphQL vulnerabilities can sometime attract relatively significant rewards on Bug Bounty Programs.

This guide reveals practical techniques – from introspection queries to mutation manipulation – for identifying and exploiting GraphQL vulnerabilities and gaining an edge over your fellow bug hunters or pentesters.

Introspection Disabled? Try a fuzzing attack instead

Mitigation & best practices for GraphQL security

GraphQL is a powerful query language developed by Facebook and open-sourced in 2015. It allows clients to request exactly the data needed from an API in a single query, thus avoiding common REST API pitfalls like over-fetching or under-fetching. 

GraphQL can handle complex, nested queries and real-time data subscriptions, making it an ideal choice for modern web and mobile applications. (This 

 explains the difference in an amusing way).

Benefits of GraphQL include improved performance, flexibility in data retrieval, and enhanced developer productivity. Built-in introspection tools allow developers to easily explore and understand API schemas, simplifying debugging and integration with backend systems. These advantages explain why growing numbers of companies are adopting GraphQL as they modernise their infrastructure.

This article focuses exclusively on potential attacks against GraphQL endpoints and does not serve as a development tutorial. For detailed development resources, please consult the 

Despite GraphQL’s advantages, it also presents a number of security risks due to the complexity and flexibility of its queries. For instance, attackers can (unless explicitly restricted) query deeply nested or unexpected fields, perform introspection queries that reveal entire API schemas, and perform multiple operations in a single request that potentially bypass rate limits and enable simultaneous malicious operations.

Common vulnerabilities found on GraphQL endpoints include information disclosure, business logic error, insecure direct object references (IDOR) and improper access control vulnerabilities.

It’s impractical to list all permutations of endpoints associated with a GraphQL instance. However, many GraphQL APIs, especially those built with frameworks like 

, commonly use standard endpoint paths such as:

. Another effective method to identify hidden GraphQL endpoints involves searching JavaScript files for keywords like "query", "mutation", or "graphql". This can reveal unofficial or decommissioned GraphQL endpoints.

GraphQL introspection lets users query an API for schema details, effectively providing self-documentation on available types, fields, queries and mutations.

This helps developers understand and interact with the API more efficiently.

If introspection is enabled on the target, that is good news. It means you gain a deeper knowledge of the API and can target specific vulnerabilities with greater precision.

During a pentest, we can use the payload below to perform a GraphQL introspection (if this feature is enabled) on our target:

The server should respond with the full schema (including query, mutation, objects and fields). While the schema is typically displayed in JSON, it often becomes unreadable due to its complexity and nested structure. In my experience, once you have retrieved the schema, the best way to simplify analysis is to import it into a tool like “

GraphQL introspection disabled? Try a fuzzing attack instead

GraphQL’s introspection is sometimes disabled for unauthorised users as a security measure. However, GraphQL’s field suggestion feature, which is enabled by default, can inadvertently reveal schema information too. The feature helps developers by suggesting corrections for mistyped fields, so if you query a field and include a deliberate typo, GraphQL will suggest fields that closely match your intended query – inadvertently facilitating your recon efforts.

Note: This abuse of field suggestions does not, technically, constitute potential vulnerabilities, since the behaviour is intended. Nevertheless, for hackers this feature is an invaluable way to gain insight into GraphQL’s schema – especially when the introspection feature is inaccessible.

It’s wise to use specialised tools rather than conducting these fuzzing attacks manually. Burp Suite Intruder is a popular option, although it requires substantial configuration to achieve accurate results for this type of attack. It’s therefore worth also trying purpose-built community tools like 

A fundamental challenge with GraphQL is the lack of a built-in access control system. Instead, developers must write custom resolvers to map queries to the appropriate database, which can introduce vulnerabilities such as improper access control and Insecure Direct Object Reference (IDOR) flaws if not done correctly.

For example, consider a legitimate query called "currentUser" that accepts an "internalId" parameter. This query should only return information for the currently connected user, who is identified by the internalId, therefore keeping other users’ data secure:

might retrieve another user’s data, indicating the presence of an IDOR – a common GraphQL vulnerability when access controls are not properly enforced.

Similarly, queries can be manipulated to extract unintended data. For instance, consider the following query, used by a newsletter web application:

If an attacker adds extra fields to this query, they may be able to extract sensitive information. This scenario underlines the critical importance of implementing strict validation and access controls in GraphQL resolvers. By using introspection or fuzzing, you might also discover additional objects such as "user" and therefore fetch additional sensitive information:

 data, mutations in the context of GraphQL are used to 

 data – which introduces the risk of vulnerabilities such as mass assignment flaws.

”, used to create a user account. This mutation accepts fields like 

. Additionally, the GraphQL response for this mutation includes a 

To test for mass assignment vulnerabilities, let’s add the 

 field directly into the mutation request to see if the application improperly accepts and applies it:

As mentioned earlier, the most difficult part of GraphQL for developers is enforcing granular, per-request access control and correctly implementing resolvers that integrate seamlessly with these controls.

 involves combining multiple requests into a single request. Akin to executing a brute-force attack but with a single request, a batching attack can bypass authentication and rate-limiting measures by simultaneously executing multiple credential tests or queries.

If you want to know more about batching attacks, I invite you to read 

Testing Tools significantly simplify GraphQL testing by visualising schemas and automating common tasks. These are two particularly useful tools for testing GraphQL more efficiently:

A Graphql schema structure can be dauntingly hard to understand since it’s usually a lot of data to take in. By visualising the composition of objects, mutations and queries through a friendly user interface, 

 simplifies the process of grasping the structure of a GraphQL schema.

 allows you to perform introspection queries and generate query templates based on discovered schemas. It also has multiple methods for schema discovery that are useful to leverage where introspection is disabled. InQL is available as a command line interface (CLI) or Burp Suite extension.

Here are some recommended measures to configure GraphQL more securely to prevent the kinds of attacks we’ve outlined:

Disable introspection in production environments

: Disabling introspection or restricting access to authorised users only prevents attackers from mapping your API schema and leaking sensitive information.

Strict authorisation checks on every resolver help to prevent unauthorised users from accessing or modifying data.

Allow the execution of pre-approved queries only by maintaining a whitelist of safe queries. This reduces the risk of arbitrary or malicious queries affecting your system.

Error messages can potentially expose sensitive information about your API or underlying system. Use generic error responses for end users, while logging comprehensive details internally for debugging purposes.

Adopting these practices significantly enhances GraphQL security, thereby ensuring a safer and more robust environment for your application and its users.

GraphQL’s flexibility is a great help to developers but also introduces unique security challenges.

While developers have differing opinions on the 

relative security strengths and weaknesses

 of GraphQL versus REST APIs, it’s clear that GraphQL offers intriguing attack surfaces for ethical hackers to explore.

Moreover, GraphQL’s versatility and use in the world’s most popular applications (including X, Shopify and Facebook to name three) means Bug Bounty payouts for GraphQL vulnerabilities can sometimes be generous.

The techniques we’ve covered for exploiting GraphQL endpoints – leveraging introspection, queries, mutations and batching – will be an invaluable part of your armoury as a pentester or bug hunter. 

Given the potential rewards, it’s worth continuing your GraphQL education beyond reading this article. For instance, it’s well worth reading 

Looting GraphQL Endpoints for Fun and Profit

 by Nick Aleks at the GraphQL Wroclaw Meetup (as well as consulting the other references listed below).

GraphQL abuse: Bypass account level permissions through parameter smuggling

 by Nick Aleks at the GraphQL Wroclaw Meetup

Hacking GraphQL endpoints with introspection, query, mutation, batching attacks

A pioneering EU cyber-certification scheme for digital products is up and running following the publication of guidelines around the management and disclosure of vulnerabilities. 

 (EUCC) scheme offers vendors of information and communication technology (ICT) products the opportunity to prove that their hardware or software meets stringent security standards.

Prerequisites for EUCC certification include providing security guidance to end users, committing to providing prompt security updates, following best practices around vulnerability disclosure, and monitoring and remediating publicly disclosed vulnerabilities.

The scheme aims to elevate and harmonise cybersecurity standards across the EU. It will also empower users to be more discriminating in terms of choosing secure products.

, the EUCC scheme has officially supplanted all equivalent national schemes. Certificates will be used by national cybersecurity certification authorities (NCCAs) following assessments conducted by accredited third-party conformity assessment bodies (CABs).

Certification is split into two levels of assurance: ‘substantial’ and ‘high’, with the latter applied to products with higher risk profiles and entailing 

The European Union Agency for Cybersecurity (ENISA) published 

EUCC Guidelines on Vulnerability Management and Disclosure

 to coincide with the scheme’s commencement. 

, this document explains how EUCC certificate holders can “maintain and publish appropriate methods for receiving information on vulnerabilities related to their products from external sources, including users, certification bodies and security researchers”.

Certificate holders must publish contact information for reporting suspected vulnerabilities, such as through a 

 file. A non-exhaustive list of applicable methods for obtaining information about potential vulnerabilities cited by the document include 

, dark web monitoring and tracking vulnerability disclosure platforms.

When a certificate holder becomes aware of a suspected vulnerability, they must perform a detailed vulnerability impact analysis to ascertain whether the bug is new, if it poses a legitimate security risk, its severity, and its potential impact on the certified product’s conformity. Vulnerability impact analysis reports should be retained for at least five years.

Validated vulnerabilities must be mitigated promptly. If the vendor becomes aware of potential active exploitation, they should notify the certification body and prioritise impact assessment and risk mitigation.

Exploit information must be handled in accordance with FIRST’s 

 or EUCC’s 'Minimum Site Security Requirements'.

Certificate holders are also instructed to adhere to 

The guidelines detail the responsibilities of certification bodies, national cybersecurity certification authorities (NCCAs), and Computer Security Incident Response Teams (CSIRTs) as they pertain to coordinated vulnerability disclosure.

In response to an invitation to comment about the relevance of VDPs, Germany’s Federal Office for Information Security told YesWeHack: “A VDP is a useful method of obtaining information from external sources about vulnerabilities in your own products. This applies not only to EUCC certificate holders, but also to many other companies and institutions.”

A voluntary scheme – but VDPs are now essential

The EUCC is currently a voluntary scheme.

, which will apply from 11 December 2027, 

 that vendors of products with digital elements (PDEs) implement VDPs (also known as coordinated vulnerability disclosure or CVD policies) if they want to sell their devices or software in the world’s largest trading bloc. Similar to the EUCC scheme, Bug Bounty Programs are also explicitly referenced as a vehicle for fulfilling CVD obligations by the CRA.

So whether they certify their products under the EUCC scheme or not, vendors of digital products can ill afford to overlook best practices for vulnerability disclosure and management – and those best practices unequivocally include VDPs and Bug Bounty Programs.

 from YesWeHack, which crowdsource the continuous testing of in-scope assets and risk-based prioritisation of the most critical vulnerabilities, are aligned with the EUCC’s emphasis on early detection and prompt remediation.

A VDP meanwhile is prescribed by the standards that the ENISA guidelines for vulnerability management and disclosure are based on: ISO 29147 and ISO 30111.

 aligned with industry best practices, such as end-to-end encryption, and integrate it into your website. The product also offers a unified interface for receiving reports, and a triage service that evaluates the severity of vulnerabilities and ensures you receive only valid, actionable reports

EUCC cyber certification scheme enters early adopter phase after vulnerability disclosure rules issued

How often have your exploits been blocked by firewalls or neutered by mysterious processes that alter key characters?

This is why payload obfuscation is such a game-changing skill for offensive security testing: by disguising malicious code as harmless data you can bypass security defences and reach your target.

This guide will walk you through everything from the basics of URL encoding and octal encoding to advanced obfuscation methods such as variable expression assignment and obfuscation in shell environments – giving you the tools to outsmart even the toughest security defences.

These skills are invaluable for Bug Bounty Programs, which often simulate real-world hacking conditions by ensuring hunters must overcome defences like web application firewalls (WAFs), input sanitisation and rate limiting.

The YesWeHack Blog

UK publishes proposals for NIS 2-equivalent Cyber Security and Resilience Bill

HTTP header hacks: basic and advanced exploit techniques explored

Spyware pact draws distinction between malicious and legitimate use of cyber-intrusion tools

UK publishes proposals for NIS 2-equivalent Cyber Security and Resilience Bill

Hacking GraphQL endpoints with introspection, query, mutation, batching attacks

EUCC cyber certification scheme enters early adopter phase after vulnerability disclosure rules issued

The art of payload obfuscation: how to mask malicious scripts and bypass defence mechanisms

Hacking GraphQL endpoints with introspection, query, mutation, batching attacks

Limitations are just an illusion – advanced server-side template exploitation with RCE everywhere

YouTube email leak exploit, Great ‘Wallbleed’ of China, Burp’s overlooked ‘best feature’ – ethical hacker news roundup

Mitigating AI cybersecurity risks with Bug Bounty Programs: A deep dive

Limitations are just an illusion – advanced server-side template exploitation with RCE everywhere

Don't wait for threats to strike

Products

Researchers

Resources

Company

Follow us