Web Application Penetration Testing Birmingham

CREST-accredited web application penetration testing for Birmingham businesses. We test your websites, portals and APIs the way a real attacker would.

Your web applications are your most exposed systems

Public websites, customer portals, booking and payment systems and APIs are all reachable from anywhere, which makes them the first thing an attacker probes. For most Birmingham businesses, a web app is where a breach is most likely to start.

What a web application test covers

We test the way an attacker would, focusing on the high-impact issues in the OWASP Top Ten: injection flaws, broken access controls, authentication weaknesses, exposure of personal data, and insecure APIs and file handling.

Clear, prioritised reporting

You get a plain-English report that rates each issue by severity and tells you exactly what to fix, plus a retest to confirm the fixes worked.

Web application testing in Birmingham

Birmingham's economy is split between professional and financial services in the city centre and a manufacturing and metals base across the wider conurbation. Those two halves need very different things from a security engagement: one is dominated by client data and sector regulation, the other by shop-floor equipment that predates the requirement being asked of it.

Testing a client portal properly means logging in

Much of what professional and financial services firms in Birmingham run is a portal of some kind: somewhere clients sign in to upload documents, check a statement or approve something. Almost all of the risk in that sort of application sits behind the login, because that is where other people's data is. A test that only sees the public pages tells you very little about whether one client can reach another client's file.

That means credentials, and credentials are the most common reason a test slips. We ask for two accounts at every permission level, created and tested by you before the first day rather than on the morning testing starts. Two per role, because the most damaging finding in a portal is usually one ordinary user reaching another ordinary user's records, and proving that needs two identities of equal standing. If accounts arrive late, lock out after a few failed logins, or send a code to a colleague's phone, the time lost comes out of the testing days.

Credentials we ask for before a portal test, and what each set is there to prove.

Level	What we ask for	What it lets us prove
External client	Two accounts, ideally belonging to two different client organisations	Whether one client can read, alter or download another client's data
Internal staff	Two accounts with ordinary staff permissions	Whether a standard account can reach records or functions meant for another team or a senior role
Administrator	One account, plus agreement on which actions are off limits	Whether administrative functions are properly protected, and what an attacker gains by taking one over
No account	Nothing	Which pages, files and endpoints answer with no login at all

Tell us as well which actions are genuinely irreversible, such as anything that emails a real client or submits a real filing, and we will set out in the rules of engagement how those are handled.

The flaws a scanner will never find

Automated tools recognise patterns they have already seen. They have no idea what your application is supposed to do, so they cannot tell that something is wrong when the application does exactly what it was built to do, for the wrong person. Most of the serious findings we report on portals are that sort of issue.

• Changing a reference number in a request and receiving a document belonging to a different client.
• A fee, limit or discount worked out in the browser and sent to the server, which accepts it without checking it again.
• An approval or verification step that can be skipped by going straight to the page that follows it.
• An invitation feature that lets a user attach a new colleague to an organisation that is not theirs.
• An export or report that ignores the filter restricting what the user is allowed to see on screen.

The same applies to the API behind the screen. Hiding a button from a junior user achieves nothing if the endpoint behind it still answers when it is called directly, and that check happens at the endpoint or it does not happen at all.

Applications that quietly became business critical

Established firms often have one in-house application, built years ago for a narrow job, added to ever since, and now holding work the business could not operate without. The developer who wrote it has moved on, the framework is several versions behind, and nobody is entirely certain what all of it does.

These are worth testing, and they are far better tested grey-box. Give us read-only access to the source, or an hour with whoever maintains it, and the days go on the parts that matter instead of on working out how it is put together. Where the budget covers fewer days, that difference decides how much of the application is actually examined.

File handling is the usual weak point at this sort of age. We check whether the file type restriction exists anywhere other than the browser, whether an uploaded document can be retrieved by someone who guesses or increments its name, whether uploads land somewhere the web server will happily execute them, and whether a document uploaded by one client can be served back to another in a way that runs code in their browser.

When a client's due diligence questionnaire arrives

In regulated sectors, and in the supply chains around them, the test is often prompted by a client rather than by your own risk register. The questionnaire tends to ask the same things: who carried out the testing and what they were accredited to do, what was in scope, when it happened, what was found, and whether the findings were fixed and checked again.

A report should answer all of that without a covering letter around it. Ours states the scope and the dates, names the accreditation the work was performed under, and the free retest gives you the second document confirming the issues are closed. If you are weighing up providers against that sort of requirement, what to ask a penetration testing provider and the difference between CREST and CHECK are both worth reading first. Cost is covered on our penetration testing cost page.

Common questions

Penetration testing for Birmingham organisations

Testing requirements in Birmingham usually arrive through a client or framework requirement, for the professional firms, and a flow-down clause from a larger customer for the manufacturers. Given a city centre dominated by professional, legal and financial services sitting on top of a metals, castings and component manufacturing base spread across the wider conurbation, the scope is most often a web application, an external infrastructure range, or both together where a customer has asked for evidence covering everything they can see.

The day count is driven mostly by how many user roles an application has and how much genuinely distinct functionality sits behind them, not by page count. We scope on a call rather than through a form, and the quote is fixed for the scope agreed. Birmingham is forty minutes from our office, so on-site work here is routine rather than a special arrangement.

Where a Birmingham requirement names CREST, check the provider holds accreditation at company level rather than relying on an individual certification: ours is verifiable on the CREST marketplace. See what a penetration test costs for ranges by test type.