Web Application Assessment

We test across the established categories, including common web vulnerability categories listed by OWASP but not confined to them. We probe injection in all its forms - including SQL, NoSQL, XXE, LDAP, ORM, prompt, command, and template injection, as well as file inclusion - as the point where untrusted input crosses a trust boundary. We test for cross-site scripting, cross-site request forgery, and server-side request forgery, the last increasingly potent against cloud-hosted applications that can be coerced into reaching internal metadata services.

Frequently, the most damaging flaws to web applications lie in access control and authentication. We test systematically for broken access control - insecure direct object references that let one user read another's records, missing authorisation on privileged functions, and both horizontal and vertical privilege escalation. And we scrutinise authentication and session management: management of cookies, passwords, tokens, sessions, and validation, and the multi-factor flows so often implemented just incompletely enough to bypass. We examine single sign-on and federated authentication (such as OAuth), and seek to identify areas where their redirect, state, or signature handling may be subtly wrong. This includes assessing JSON Web Token implementations for algorithm-confusion and weak-signing-key flaws. We also probe password reset and account recovery, where predictable tokens and host-header-poisoned reset links are among the most direct routes to full account takeover. We conduct our tests both unauthenticated and, with credentials you provide, authenticated - frequently across several privilege levels, as the worst flaws can concern privilege escalation by users who are already logged-in.

We can further look for web vulnerabilities rooted in the application's business logic itself. We test the application's logic against its intent, with a particular eye for race conditions (such as access before authentication or time-of-check to time-of-use issues). We also focus on testing complex multi-step workflows and finding the states the developers never anticipated - prices and quantities tampered with, mandatory steps skipped or replayed, and discount or referral logic abused in ways no scanner could recognise. Where the application exposes an API, whether REST or GraphQL, we test it as a first-class attack surface in its own right, down to object- and function-level authorisation and the over-fetching that GraphQL introspection so often enables.

The most serious web vulnerabilities do not stop at the application; they hand an attacker the server underneath it, and we test specifically for the classes that make that leap. An unrestricted file upload becomes a web shell wherever extension or content-type checks can be bypassed. Insecure deserialisation of attacker-controlled data can yield remote code execution through crafted gadget chains in Java, PHP, .NET, or Python. Server-side template injection, where untrusted input reaches the rendering engine, frequently escalates to full command execution. We test for local and remote file inclusion and path traversal that expose source code, configuration, and credentials - and we follow server-side request forgery beyond the application itself, since a single SSRF can often be pivoted through internal services to a cloud metadata endpoint, and from there to the credentials governing your entire hosting environment. These are the findings that turn a bug in a web form into an attacker on your network.

Beyond the application's own logic sits a layer of configuration and client-side behaviour that attackers exploit routinely. We assess the security headers that constrain what a browser will do on your behalf - content security policy, HSTS, frame options - alongside cookie attributes such as HttpOnly, Secure, and SameSite, and the CORS configuration that, when too permissive, quietly hands your data to any origin that asks. We test for clickjacking, open redirects, and prototype pollution, and for the verbose errors, exposed source-control directories, and stray backup files that leak internal detail. And we probe for missing rate limiting and the differential responses that let an attacker enumerate valid usernames or brute-force credentials unhindered - the absence of which makes every other weakness easier to reach. Our work centres on an intercepting proxy that lets us observe and manipulate every request and response, but the testing is led throughout by judgement about how the application is meant to behave and how to make it behave otherwise.

Modern cryptography is arguably the most technically advanced security technology in history, and properly applied it is the strongest defence web applications can have. At its best, it can reduce the complex problem of managing the security of arbitrary data that must inherently be passed across a network to the simpler problem of securing keys, much smaller pieces of data. The magic of public-key cryptography can (where applicable) simplify the problem even further by enabling the sensitive keys to remain entirely local, with all keys sent over the wire either public or themselves encrypted. Yet it is also easy to misapply, and cryptography should not be assumed to be inherently secure unless carefully tested. The security of your web application's cryptography has the potential to go far beyond whether your website uses HTTPS and TLS; many websites explicitly invoke cryptographic functions in the frontend or backend or both, or rely on third-party frameworks or libraries that do. Even a very simple website likely (and should) be invoking a hashing algorithm if it has some way for a user to log in.

The moment your web application needs to explicitly manage cryptography or hashing, all the usual ways in which cryptography may be insecurely implemented surface: improper key management, weak ciphers or hashing algorithms, rainbow tables for unsalted hashes, predictable keys, plaintext information leakage from ECB, integrity-targeting attacks such as bit-flipping or length extension. Our Web Application Assessment includes a thorough test of your application's cryptography and hashing, both transport-layer security and any custom use of hashing or encryption in your application.

Some attackers are not after your data. Some merely wish to harm your website directly - simply to harm your organisation, to hold your web application itself ransom, or for other reasons. A specific family of attacks against web applications targets not the data on their servers but rather simply their uptime, and testing the viability of these attacks is a distinct domain of our Web Application Assessment.

The most famous of these are distributed denial-of-service attacks. DDoSing works by trying to overwhelm a server with traffic. The amount of traffic a modern DDoS attack can bring to bear is truly immense. Modern botnets include many millions of devices making requests. To make matters worse, techniques like reflection amplification attacks allow each device to increase the volume of traffic they can direct towards your website beyond what their own bandwidth would allow by bouncing their traffic off third-party systems (such as exposed DNS services). While Shellhex cannot directly perform DDoS attacks, we can still try to estimate the quality of your DDoS protection, such as any reverse proxy services like Cloudflare that you use.

More sophisticated are denial-of-wallet attacks. Whenever a client submits a request to a server, some computation is performed. If the request simply means returning a static page, it is fairly clear that the server can do this task quickly. But many requests are far more complex. Determining whether an arbitrary computation terminates is famously impossible - the halting problem is undecidable - so in general, guaranteeing that a complex user-generated request completes in reasonable time requires that its resources are explicitly bounded. Without explicit resource limits and timeouts of requests, in general it may be possible for a user to trick a server into performing so much computation that it crashes - or ramps up a costly cloud server bill.

A final category of attacks on uptime are aggressive web scrapers. The need for internet-scale text data for training LLMs has hugely increased the economic value of web scraping, making it now quite possible for websites to be overwhelmed by the aggressive scrapers constantly crawling the internet. Simple firewalls are insufficient to prevent this, as the use of residential proxies enables scrapers to use high-reputation IPs and masquerade as normal traffic. Realistic mitigations currently include tools like Anubis.

You receive a report in which every finding is reproducible step by step, rated in the context of what the application protects, and accompanied by remediation guidance pitched at your developers. Our goal is to enable your engineering team to remediate the underlying class of issue rather than solely the specific instance we happened to find, and we can offer a free consultation meeting as part of our Web Application Assessment to advise them on this. We are happy to explore opportunities for further engagements and assessments to retest once fixes are in place. For teams shipping continuously, we can align testing with your release cadence and advise on the process and DevOps strategies - secure-by-default frameworks, dependency scanning, security review in the pipeline - that minimise the chances of flaws recurring.