At a glance
A large public-sector organisation operating one of Pakistan’s most heavily used citizen-facing web portals engaged ZealsTECH to put its production application through a focused black-box penetration test. The portal handles new-service registrations, complaint submissions and an administrative back-office, all reachable from the open internet. Because the platform is consumer-facing and processes identity data at scale, the client needed independent assurance that its controls held up under adversarial conditions — not just under routine QA.Our SecOps team approached the assessment the way an external attacker would: with no prior knowledge of the system, no credentials, and no help from the development team. Over the course of the engagement we identified six distinct issues across the front-end input layer, the API perimeter and the transport configuration. One issue was rated High; four were rated Medium; one was informational. None of the findings were theoretical. Each one was reproduced end-to-end, with full evidence handed back to the client.
“The most damaging weaknesses we found were not exotic. They were ordinary input-validation gaps that had simply been trusted to the browser. Once the request left the browser, no one was checking it again.”
A public-sector platform with no margin for downtime
Our client is a large public utility based in Pakistan that serves several million end users through its online portal. For privacy reasons the organization is not named in this document; both the entity and its infrastructure details have been deliberately anonymised. What matters for context is the scale and the sensitivity: the application accepts personal identity information from members of the public, drives back-office workflows for staff, and is, in practical terms, a primary channel of contact between the organisation and the people it serves. The leadership team had already invested in conventional protections — TLS, WAF rules at the perimeter, and basic monitoring but wanted to know, in concrete terms, what an external attacker could actually do. That is the question a penetration test is built to answer.
A black-box test, defined narrowly and executed deeply
The engagement was scoped to a single production web application and its supporting API surface. We worked without credentials, without source code, and without internal documentation — the standard black-box posture. The intent was to mirror the position of a motivated outsider who has done their homework on the application but has no insider advantage. Three classes of activity were explicitly out of scope, by agreement with the client. We did not run intrusive tests designed to crash services, we did not execute denial-of-service attacks of any kind, and we did not deface or otherwise tamper with payment-related interfaces. Everything else within the perimeter of the application was fair game. Findings were assessed against four reference frameworks that the client cares about: OWASP, NIST, PCI-DSS v3.2.1 and SOC 2. Each issue was tied back to specific control gaps so the remediation roadmap could double as evidence for compliance.
Six issues, one recurring root cause
When the six findings are lined up next to each other, a pattern is hard to miss. Four of the six are different facets of the same underlying problem: validation logic that lived only in the browser. If a user filled the form the way the developers expected, everything worked. If a user — or an attacker — bypassed the form and sent the request directly, the back-end accepted whatever it received. That single design assumption is what produced the most serious finding in this report, and it is the thread that runs through everything that follows.
What we found, what it meant, and how we proved it
Finding 01 · Database error leakage
What it was. On one of the public forms — the one used to start a new-service request — the identity field was being validated only in the browser. When the request was intercepted and the field was inflated with an oversized payload, the back-end did not reject the input or return a generic error. Instead, it surfaced a raw database error message that named tables, columns and the structure of the underlying query.
Why it mattered. An attacker doing reconnaissance for a SQL-injection attempt usually has to guess at schema. Here, the application was handing schema out for free. Combined with the other input-validation gaps in this report, the path from harmless-looking form to targeted injection attempt was uncomfortably short.
How we remediated it. We worked with the client to switch off verbose error reporting on production, introduce a generic error envelope at the API layer, and enforce strict server-side validation on the affected field. WAF rules were tuned to flag abnormally long payloads as an additional safety net.
Finding 02 · Rate-limiting bypass
What it was. The API endpoints exposed standard rate-limit headers, but the underlying counter keyed off a client-supplied address header. By rotating that header across a range of values, we were able to drive nearly a hundred login attempts at the administrative endpoint without ever tripping the throttle.
Why it mattered. Rate limiting is one of the cheapest and most effective controls against brute-force and credential-stuffing attacks. If it does not work, every other authentication weakness — predictable passwords, weak account-recovery flows, slow lockouts — becomes dramatically easier to exploit.
How we remediated it. The fix had two parts. The proxy in front of the application was reconfigured so that only its own trusted client-address header was honoured. The rate-limit key itself was hardened so that it combined network identity with account and session signals rather than relying on IP alone. Limits were also moved one tier outward, to the API gateway, so they could be enforced consistently regardless of the upstream application.
Finding 03 · Identity field accepts arbitrary input
The same form involved in Finding 01 carried an identity field expected to contain a 13-digit numeric ID. The format check, again, lived only in the browser. By sending the request directly, we were able to submit free-form alphanumeric strings and have them accepted, stored and processed downstream. The integrity implications are obvious: records can be created against identifiers that do not correspond to any real person, which is exactly the kind of data quality issue that erodes trust in a customer database over time.
Remediation was a strict server-side check — numeric only, exactly thirteen characters, anything else rejected before it reaches business logic.
Finding 04 · Service-type field accepts arbitrary values
The form offered a dropdown to choose a service type, with the legal values constrained on the front-end. Bypassing the dropdown by sending the request directly allowed us to inject any value we wanted into that parameter. Where the back-end had branching logic keyed off this value, the consequence was unexpected valid-looking records were being created for services that were never meant to exist in the workflow. We recommended a strict allow-list on the server: if a value is not on the canonical list, the request is logged and rejected.
Finding 05 · Origin server reachable without valid TLS
The application could be reached directly on its origin IP address, bypassing the published hostname. Because the certificate was issued only for the public hostname, traffic to the IP was served over an untrusted transport opening the door to interception and man-in-the-middle attacks for anyone routed around the front door. The remediation was to restrict origin access at the load balancer, force a redirect to the canonical hostname, and ensure no legitimate user agent ever resolved the IP directly.
Finding 06 · Missing Content-Security-Policy header
The application served no Content-Security-Policy header. On its own, this is not exploitable — but it removes a defensive layer that would otherwise contain the damage of a successful cross-site scripting attempt elsewhere. We worked with the team to roll out a starter policy in report-only mode, observe the telemetry for a fortnight, and then promote the policy to enforcement once the inventory of legitimate script
sources was settled.