services / web-application-penetration-testing

Web Application
Penetration
Testing

We test your application as an authorised attacker would — combining manual exploitation, business-logic analysis, access-control testing and API testing to identify vulnerabilities that automated scanning can miss.

Illustrative example
request.http
idor_test.http
auth_bypass.http
GET /api/v1/invoices/8841 HTTP/1.1 Authorization: Bearer <user_A_token> # Response — 200 OK, returns user B's invoice IDOR — BOLA { "invoice_id": 8841, "owner": "user_B", "amount": 42500 } POST /api/v1/password-reset HTTP/1.1 { "email": "victim@corp.com", "role": "admin" } # ⚠ Mass assignment — role field silently accepted GET /search?q=%27+UNION+SELECT+*-- # ⚠ SQLi confirmed — 340ms → 6100ms time-based delay # ✅ Fix: parameterised queries + object-level auth checks
overview

Web Application Penetration Testing, Built for How You Ship

Web application penetration testing is an authorised, human-led attack simulation against your live product — not an automated scan. Grey Shield's engagements combine manual exploitation, business-logic testing, and API testing to find the flaws that matter before a real attacker, auditor, or enterprise customer does. Every engagement follows the Grey Shield testing methodology, aligned to the OWASP Web Security Testing Guide and PTES.

We work with Indian SaaS platforms and fintech products where a single missed access-control bug can mean cross-tenant data exposure or a compromised payment flow — the kind of finding a generic vulnerability scanner is not built to catch. Our reports are written to be usable twice: once by your developers to fix the issue, and once by your security or compliance team to answer an enterprise customer's questionnaire or auditor's request.

New to Grey Shield? Read more about our team, browse recent case studies, or go straight to requesting a scoping call.

Our approach is informed by the OWASP Web Security Testing Guide. For deeper source-level coverage, see our source code review; for API-focused assessments, see API security testing.

// for SaaS teams

Multi-Tenant SaaS Platforms

Tenant isolation, role-based access control, subscription and billing logic, and API endpoints tested against every plan tier and user role — ahead of a security review from an enterprise prospect.

// for fintech teams

Fintech & Payment Products

Authentication, KYC and onboarding flows, transaction and payment logic, and API integrations tested for the abuse cases that put customer funds and financial data at risk.

// for growth-stage teams

Pre-Funding & Pre-Audit

A structured, evidence-backed report you can hand to investors, enterprise procurement teams, or auditors as proof that your application has been independently tested.

vulnerability classes

What We Find

Coverage is scoped to the application and threat model, with testing informed by the OWASP Web Security Testing Guide and relevant OWASP application and API risks.

injection.sql / xss.js CRITICAL
Injection & XSS

SQL, NoSQL, and command injection; reflected, stored, and DOM-based XSS; server-side template injection — traced from every user-controlled input to its sink.

SQLiXSSSSTI
auth_flow.session CRITICAL
Broken Authentication & Session Management

Credential stuffing resistance, weak password reset flows, session fixation, JWT algorithm confusion, predictable tokens, and missing MFA enforcement on sensitive actions.

JWTMFASession
access_control.rbac CRITICAL
Broken Access Control (IDOR / BOLA)

Insecure direct object references, broken object and function-level authorization, horizontal and vertical privilege escalation across every user role in the application.

IDORBOLARBAC
business_logic.flow HIGH
Business Logic Abuse

Price manipulation, coupon and discount stacking, race conditions in checkout and withdrawal flows, workflow step-skipping, and negative-quantity or overflow abuse.

Race ConditionsWorkflow Bypass
api_endpoints.rest / .graphql HIGH
API Security (REST & GraphQL)

Excessive data exposure, mass assignment, missing rate limiting, GraphQL introspection abuse and nested query denial-of-service, and broken function-level authorization across endpoints.

RESTGraphQLRate Limiting
config.env / headers MEDIUM
Security Misconfiguration

Missing security headers, verbose error messages leaking stack traces, exposed debug endpoints, permissive CORS policies, and outdated components with known CVEs.

CORSHeadersCVEs
how we work

Testing Methodology

Aligned to the OWASP Web Security Testing Guide (WSTG) and PTES — manual-first, role-aware, and mapped to real user journeys. This is the web-application-specific application of our core testing methodology.

// PHASE 01

Scoping & Application Mapping

Walk through every user role, feature, and workflow. Map the full application surface — pages, API endpoints, hidden parameters, and third-party integrations in scope.

// PHASE 02

Automated Reconnaissance & Baseline

Use appropriate automated tooling to identify common signals and map areas that deserve deeper manual attention. Automated output is validated rather than copied into the final report.

// PHASE 03

Manual Exploitation

Manually test authentication, session handling, access control, and every input field for injection — proving impact with working proof-of-concept requests, not theoretical risk.

// PHASE 04

Business Logic & Access Control Testing

Test each feature against every user role to surface IDOR, privilege escalation, and workflow abuse that requires understanding the application's intent to uncover.

// PHASE 05

API & Integration Testing

Test REST and GraphQL endpoints directly — bypassing the front-end to probe authorization, rate limiting, and data exposure at the API layer.

// PHASE 06

Reporting, Remediation & Retesting

Deliver evidence-backed findings with impact, reproduction details and practical remediation guidance. Retesting can be scoped after remediation to verify whether reported issues have been addressed.

tools & frameworks

What We Use

Industry-standard tooling backed by manual, human-led exploitation — no report is ever a raw scanner export.

Intercepting Proxy API Testing HTTP Fuzzing Browser Testing Authentication Testing Authorization Testing Business Logic Testing Custom Test Cases
deliverables

What You Get

findings_report.pdf

Annotated Findings Report

Every vulnerability documented with affected endpoint, request/response evidence, CVSS score, and exact fix recommendations ready for your developers to action.

exec_summary.pdf

Executive Summary

A non-technical summary of application security posture, risk exposure, and top-priority fixes — written for leadership and product stakeholders.

findings.csv / SARIF

Developer-Ready Findings

Findings are structured so engineering teams can understand the affected component, reproduce the issue, assess impact and plan remediation. Export formats can be agreed during scoping where required.

retest_confirmation.pdf

Retesting After Remediation

After fixes are deployed, retesting can verify whether previously reported findings have been remediated. Retest scope and timing are agreed as part of the engagement.

debrief_call.cal

Developer Debrief Session

A live walkthrough with your engineering team explaining each attack scenario, answering fix questions, and advising on secure coding patterns going forward.

compliance_mapping.csv

Security & Compliance Context

Where relevant to the engagement, findings can be organised against the security framework or customer requirement supplied during scoping. Specific compliance mapping is subject to scope.

related security coverage

Web application testing is one part of an application security program. Add the coverage that matches your architecture and risk.

// SOURCE LEVEL

Source Code Review

Review security-sensitive implementation details, data flows, authorization logic and other code-level weaknesses that runtime testing may not expose.

// API LAYER

API Security Testing

Assess API authentication, authorization, object access, data exposure and business logic across the interfaces your application depends on.

// DELIVERY

Grey Shield Methodology

See how Grey Shield scopes, tests, documents findings and supports remediation across security engagements.

frequently asked

Common Questions

Straight answers about scope, coverage, and what a web application penetration test actually involves.

What is web application penetration testing?
Web application penetration testing is an authorised, simulated attack against a web application to identify exploitable security flaws such as injection vulnerabilities, broken authentication, insecure access control, and business logic abuse — going beyond automated scanning to prove real-world impact through manual exploitation.
What's the difference between a vulnerability scan and a web application pentest?
A vulnerability scan uses automated tools to flag known signatures and misconfigurations, often producing false positives and missing logic-based flaws. Web application penetration testing adds manual, human-led exploitation to confirm real exploitability and uncover business logic and access control issues that scanners can't detect.
Does this cover the OWASP Top 10?
Testing is informed by the OWASP Web Security Testing Guide and relevant OWASP application security risks. The exact test set is adapted to the application's architecture, features, roles and agreed scope.
Can this include API testing?
Yes. API testing can be included where APIs are part of the application scope. For dedicated API assessments, see our API security testing service.
How long does a web application penetration test take?
Assessment duration depends on application size, user roles, workflows, APIs and agreed scope. Grey Shield provides the expected testing and reporting schedule during scoping.
Do you need our source code to test?
No. Testing is typically performed as black-box or grey-box testing using valid credentials for each user role, without requiring source code access. Source code review is available as a separate, complementary service for deeper coverage.
Is this suitable for Indian SaaS and fintech products handling customer or financial data?
Yes. The assessment can be scoped around SaaS and fintech workflows such as multi-tenant access, billing or payment flows, onboarding and role-based access control. Any regulatory or customer-specific mapping should be agreed during scoping.
// ship it with confidence

Find the Flaws
Before Launch

Send us your application — we'll test it the way a real attacker would and return findings your developers can act on immediately. The testing schedule is agreed after scope, access and testing-window requirements are confirmed.