Web Application Security Assessment
A fixed-scope, OWASP-aligned security assessment of one web application. We review authentication and authorization the way your app actually enforces them, test input handling and session management against the OWASP Top 10, scan dependencies and configuration for known vulnerabilities and exposed secrets, and review the Azure services around the app — App Service configuration, TLS and headers, Defender for Cloud posture. You get a severity-ranked findings report with reproduction steps and a remediation plan your developers can execute. To be plain about what this is not: it is a structured security assessment, not a certified penetration test — if a contract or insurer explicitly requires a certified pen test, this service will not satisfy that requirement, and we will tell you so before you buy.
What this engagement is
Most security work around Microsoft 365 and Azure stops at the platform: tenant configuration, identity, endpoints. The application you built — or had built — sits on top of all of it, holding your customer data behind code that no baseline or secure-score report ever looks at. If that application faces the internet, it is being probed today. This assessment looks at the application itself. The risk lens is the OWASP Top 10 — the 2025 edition — with testing guided by the OWASP Web Security Testing Guide and depth calibrated against the OWASP Application Security Verification Standard. In practice that means we work through the things that actually get web apps breached: broken access control (can user A read user B's records by changing an ID in the URL?), authentication and session weaknesses, injection and input-handling flaws, security misconfiguration, vulnerable and outdated components, and secrets that leaked into code, config, or client-side bundles. Because most of the applications we assess run on Azure, the hosting layer is in scope too: App Service configuration, TLS and security headers, network exposure, WAF posture, and a triage of what Microsoft Defender for Cloud is already telling you about the app's resources. Applications hosted elsewhere get the general configuration review; the Azure-specific hardening applies where there is Azure to harden. The engagement is grey-box by preference: you give us test accounts for each role and we test what an authenticated, motivated user could do — which is where the findings that matter usually live. Everything runs under written rules of engagement agreed before any testing starts. The output is a findings report with severity, evidence, and reproduction steps, plus a remediation plan ordered by risk — written for the developers who will fix it, not for a shelf.
Success criteria
What you receive
How the work unfolds
Agree exactly what will be tested and how: the application and environments in scope, test accounts per role, testing windows, what is off-limits, and how we handle anything critical found mid-engagement. Nothing is tested before this is signed.
Map the application's exposed surface and review the hosting configuration: DNS and TLS, security headers, error handling, exposed endpoints and admin interfaces, and the platform posture around the app.
The core of the engagement. Using the role-based test accounts, we work through authentication flows, session management, access control (horizontal and vertical), input handling, and business-logic abuse cases — testing guided by the OWASP Web Security Testing Guide against the OWASP Top 10 risk categories.
Scan the application's components for known vulnerabilities and the in-scope code and configuration for exposed secrets — connection strings, API keys, tokens — including what ships to the browser.
Review App Service and surrounding Azure resources against Microsoft's security guidance, and triage the Defender for Cloud recommendations that apply to the application, separating the material from the noise.
Deliver the findings report and remediation plan, then walk your developers through every finding — reproduction, impact, and fix — so remediation starts with understanding rather than a PDF.
Prerequisites
Who does what
IT Partner
- Define and document the scope and rules of engagement, and stay inside them
- Perform the configuration, authentication, authorization, and input-handling review against OWASP guidance
- Run the dependency and secrets scans and interpret the results
- Review the Azure hosting layer and triage Defender for Cloud findings for the application's resources
- Report immediately, out of band, on any critical finding — not at the end of the engagement
- Deliver the findings report, remediation plan, and walkthrough session
Your team
- Provide written authorization, test accounts, and the agreed access before testing starts
- Confirm vendor and hosting-provider permissions where they apply
- Nominate the developer contact and the emergency contact
- Keep the in-scope environment stable during the testing window — mid-assessment deployments invalidate results
- Own remediation decisions and their execution, with our plan as the map
What's not included
Limitations & technical notes
Frequently asked questions
Is this a penetration test?
No, and we will not blur the line. A certified penetration test is delivered under a recognized certification or accreditation and produces an attestation some contracts and insurers specifically demand. This is a structured security assessment aligned to OWASP guidance: much of the same testing, honestly scoped, at assessment pricing. For most companies that need to know whether their application has real, exploitable weaknesses — and what to fix first — this is the right instrument. If your customer contract or cyber-insurance policy names a certified penetration test as a requirement, tell us; we would rather point you at the right engagement than sell you the wrong one.
What do you actually test against?
The risk framing is the OWASP Top 10, 2025 edition. The testing itself is guided by the OWASP Web Security Testing Guide, and we calibrate depth using the OWASP Application Security Verification Standard (ASVS 5.0). Concretely, the bulk of the work goes into access control, authentication and session handling, input handling and injection, security misconfiguration, vulnerable components, and secrets exposure — because that is where web applications actually get compromised.
Do you exploit the vulnerabilities you find?
We validate them safely and stop. If we find an access-control flaw, we demonstrate it with our own test accounts — we do not read your customers' data to prove the point. No data exfiltration, no persistence, no pivoting, no denial of service. Anything critical is reported immediately through the emergency contact agreed at scoping, not saved for the final report.
Can you test our production environment?
Yes, within written limits: non-destructive testing only, in agreed windows, with an emergency contact on both sides. A staging environment is better — we can test harder and you get deeper findings. The strongest setup is staging for the aggressive work plus a light production pass to confirm the configuration actually matches.
The application was built by an outside vendor. Can you still assess it?
Yes — vendor-built applications are a large share of what we assess, and often the reason for the engagement: you carry the breach risk for code you have never seen inside. You need the vendor's or hosting provider's permission for testing, which we help confirm at scoping. Findings inside the vendor's code go to them to fix; the report gives you specific, evidenced language for that conversation instead of a vague complaint.
What does it cost?
From $4,950, scoped by the application — size, number of roles, environment access, and whether source is available all move the effort. After a short scoping call you get a fixed quote in writing before any work begins, and you pay after you approve delivery. One application per engagement; a portfolio gets a per-app quote.
What do you need from us to start?
Four things: written authorization from whoever owns the application, test accounts for each role, the agreed level of access to configuration and source, and a developer we can ask questions. With those in place, the two-week clock starts at the rules-of-engagement signature.
Will this help with SOC 2, ISO 27001, or customer security questionnaires?
It is strong evidence, not a certificate. The report — scope, method, findings, remediation — is exactly the artifact auditors and enterprise customers ask for when they want to see that application security is tested rather than asserted. If an audit is the actual driver, look at our SOC 1, SOC 2, ISAE 3402 Pre-Audit Readiness Assessment — the application assessment slots into that preparation cleanly.
Do you fix what you find?
The engagement delivers the map, not the repairs — deliberately, so the assessment stays independent of the fixing. Hosting-layer remediation is available through Securing your Azure Environment and Applications; application-code fixes can be scoped as separate development work. The remediation plan is written so that whoever fixes it — us, your team, or your vendor — starts with reproduction steps and a target state, not a finding title.
Do you retest after we fix the findings?
Re-validation of remediated findings is a separate, smaller engagement, quoted when you are ready — typically a fraction of the original assessment since scope is limited to the fixed items. We keep it separate deliberately: teams remediate on their own schedule, and paying for a retest inside the assessment fee would mean paying for it whether or not you use it.
What about everything else that faces the internet — not just this app?
Different instrument. Microsoft Defender EASM maps your whole external attack surface — domains, hosts, exposed services — continuously, which tells you what else deserves this kind of assessment. And if your Microsoft 365 tenant has never had a security review, the Free Microsoft 365 Security Assessment is the zero-cost place to start.