React Penetration Testing for Single Page Applications
React penetration testing begins with a simple fact: a React app hides very little. A secret in a REACT_APP_ or VITE_ variable sits in the bundle for every visitor to read. CREST-certified testers, fixed price from £2,650 for a 2-day single-framework scope, quoted within 24 hours.
- Unlimited retesting
- No rescheduling or cancellation fees
- Fixed quote within 24 hours
“I would highly recommend EJN Labs to any organisation seeking reliable, detailed, and well-managed penetration testing services, particularly for government or enterprise-level projects.”
“There wasn’t another company we could find that could deliver what we needed in the timeframe we needed. The client loved it, and we got instant ROI from the engagement.”
React moves the application into the browser, which means it also moves the temptation. Hiding a button, guarding a route or filtering a list in the front end feels like access control, and it looks like access control in a demo. To anyone reading the bundle it is a list of features to try directly against the API.
The interface is not the boundary. The API is.
The failure modes are specific and repeatable. A route guard that hides the admin screen while the API behind it answers any signed-in user. A secret key in a REACT_APP_ or VITE_ variable. dangerouslySetInnerHTML fed with data from the API. A token written to localStorage. Source maps left public on the production host.
Create React App and Vite inline every REACT_APP_ or VITE_ variable into the bundle at build time, and their own documentation says not to put secrets there. Create React App also generates production source maps unless GENERATE_SOURCEMAP is set to false. The Create React App documentation puts it plainly: anyone can view them by inspecting your app’s files.
We test it from outside the interface. We read the bundle and source maps for keys and endpoints, call every endpoint as a lower-privileged user, try other users’ object IDs, and push script into each field the application renders as HTML. ISO 27001, SOC 2, PCI DSS and Cyber Essentials Plus audits accept manual penetration test evidence. Scan-only evidence is generally insufficient.
REACT SPECIFICS
What We Actually Test in a React Application
Ten test areas that apply because the front end is React, on top of the standard application checks. Every finding is verified, reproducible and mapped to OWASP, CWE and CVSS 3.1.
Authorisation enforced in the browser
Route guards, conditional rendering and disabled controls tested against the API directly, with each role we are given.
Endpoint enumeration from the bundle
Every API path the application references, including staff-only and legacy routes, then tested for object level authorisation.
Secrets in the build
API keys, third-party configuration and internal hostnames inlined at build time through public environment variables.
Source maps and chunks
Whether map files are served in production and what the chunk files reveal about internal endpoints, feature flags and unreleased functionality.
DOM XSS sinks
Raw HTML rendering, markdown and rich text components, sanitiser configuration, and third-party widgets that write into the DOM.
Token storage and session handling
Where the access token lives, what an XSS finding would reach, refresh token handling, and logout across tabs.
Authentication flows
OAuth and OIDC as implemented in a browser app: redirect URI validation, PKCE, implicit flow leftovers, and social login edge cases.
State and cache leakage
Persisted stores, query caches and service workers that keep one user data visible after another signs in.
Headers and content security policy
Whether a policy exists that a single page application can live with, clickjacking protection, and the effect on the XSS findings above.
Uploads, previews and rendering
Signed URL handling, preview components, and SVG or HTML rendered from user content.
METHODOLOGY
What a React finding looks like
Written the way a finding appears in our reports. The example below is reconstructed from publicly documented research, with hosts, paths and identifiers redacted. We do not republish client findings, named or anonymised.
Markdown rendered through dangerouslySetInnerHTML gives stored cross-site scripting
- Affected
- The comment thread on the project view at [redacted], React single page application, session token held in browser storage.
- What we found
- User supplied markdown was converted to an HTML string in the browser and passed to dangerouslySetInnerHTML with no sanitisation. A comment containing an image tag with an error handler executed for every user who opened that project, including two administrators.
- Why it matters
- The payload read the session token out of local storage and sent it to an external host, so any commenter could take over an administrator session without any interaction beyond the victim opening the page.
- Fix
- Sanitise the converted HTML with a maintained library such as DOMPurify, or render markdown to a React element tree rather than to a string. Move the session token into an HttpOnly cookie and add a content security policy that blocks inline handlers.
Reconstructed from public research: the React documentation, which states that dangerouslySetInnerHTML carries the same risk as setting innerHTML directly, and CVE-2018-6341 for the same class in ReactDOMServer.
React Penetration Testing: From Scope to Attestation
CREST-aligned methodology built on OWASP Web Security Testing Guide, OWASP ASVS, NIST SP 800-115, and PTES. Each finding maps to all four standards plus your specific compliance regime.
Reconnaissance
Application mapping, technology fingerprinting, content discovery, parameter enumeration, authentication-flow analysis, role-matrix construction.
Vulnerability Assessment
Authenticated and unauthenticated automated scanning across every user role, plus targeted manual checks for known weakness patterns.
Manual Exploitation
Hands-on testing by a CREST-certified pentester. Business-logic exploitation, chained vulnerabilities, privilege escalation, impact validation.
Reporting + Retest
Executive summary, technical report with CVSS scores and reproduction steps, walkthrough call, free retest after remediation, attestation letter.
CREDENTIALS
Verified Accreditations Auditors Accept
Every credential below is independently verifiable. UK procurement teams, FCA supervisors, ISO 27001 / SOC 2 auditors, and cyber insurance underwriters all recognise these standards.
GET YOUR QUOTE
Get a CREST React application pen test quote in 24 hours
A fixed-price quote back in one business day, from a named CREST assessor. No sales pipeline, no chasing.
- CREST and IASME accredited. Testing your auditors and clients already recognise.
- Fast-track testing within 24 hours where required. Free retest of every fix included.
- Live findings via your client portal, not a four-week PDF.
- Fixed price from £2,650 for a small, single-scope engagement, agreed up front. Most engagements run £3,890 and up. No day-rate surprises.
Dan WilcocksonFounder, CelloriUnder NDA Further named references available on a scoping call.
- We reply within one business day with a fixed-price quote from a named CREST assessor.
- You approve the scope and we book a start date, usually within 24 hours.
- Live findings land in your client portal as we test, with a free retest of every fix.
Get your fixed pen test quote in 24 hours
Quote request received
We will reply within one business day with your fixed-price quote from a named CREST assessor.
Your data stays with us. No newsletter signup.
or book a 20-min scoping call first
We reply within one business day. Your data stays with us. No newsletter signup.
COMPLIANCE READY
Reports Mapped to Every Framework
Findings are explicitly tagged to the relevant control reference. Your audit team submits the report directly without translation work.
ISO 27001:2022
Annex A.8.8 management of technical vulnerabilities plus A.5.15-5.18 and A.8.2-8.5 access control validation.
SOC 2 Type I & II
CC6 logical access, CC7 system operations, CC8 change management evidence.
PCI DSS
Requirement 11.4 application penetration testing across cardholder data environments, including ecommerce penetration testing for online retail platforms.
FCA SYSC
SYSC 4.1.1R, 6.1.1R, 13 mapped to each finding for FCA-regulated firms.
UK GDPR
Article 32 effectiveness testing, customer-data security controls, ICO-acceptable evidence.
Cyber Essentials Plus
Direct certification through our IASME body status, single-vendor delivery.
PRICING
Transparent React Penetration Testing Pricing
Pricing depends on app complexity, user-role count, business-logic depth, and integration surface. The day count flexes; the included deliverables stay the same across all engagements.
2 to 3 testing days
Single user role, basic CRUD application, marketing website with auth. Around 5 working days from kickoff to report.
Get a fixed quote3 to 5 testing days
Multi-role SaaS, business application with payment integration. Around 8 to 12 working days from kickoff to report.
Get a fixed quote5 to 7 testing days
Multi-tenant platform, complex authorisation matrix, integration-heavy applications. Around 15 to 20 working days from kickoff to report.
Get a fixed quotePart of Technologies We Pen Test. These are examples of the stacks we publish pages for, not a complete list. If yours is not here we still test it. Related pages:
BY SECTOR
React Penetration Testing for Your Sector
Sector-specialist scoping for UK businesses with sector-specific compliance regimes and threat models.
Fintech & FCA-Regulated
FCA SYSC, Open Banking FAPI 1.0, PSD2 SCA, payment-flow scrutiny, KYC/AML testing.
Fintech sector pageSaaS Companies
SOC 2 Type I & II evidence, multi-tenant boundaries, role escalation, customer-tenant isolation.
SaaS sector pageLaw Firms
SRA Cyber Standard, privileged data, conveyancing fraud defence, partner-tier procurement.
Law firm sector pageHealthcare
NHS DTAC, DSP Toolkit v6, UK GDPR Article 32, EHR systems, telehealth platforms.
Healthcare sector pageInsurance
FCA / PRA Operational Resilience, cyber underwriting, claims data, broker portals.
Insurance sector pagePublic Sector
CCS / G-Cloud framework, NCSC-aligned, citizen-facing services, PSN-compliance scrutiny.
Public sector pageWHY EJN LABS
What You Get From React Penetration Testing
Six concrete differentiators competitors don’t all match.
CREST-Certified Testers, Verifiable
Every test by a CREST-certified pen tester (CRT, CCT APP, CCT INF where applicable). Verify our company status at crest-approved.org.
24-Hour Startup, Where Required
From signed scope to active testing in a single business day for incident response, audit deadlines, or regulator-driven timelines.
Live Findings, Not 4-Week PDFs
Critical issues reported during testing through your client portal. Your team remediates while testing continues.
Audit-Ready Reports
Executive summary plus full technical report with CVSS scores and explicit framework mappings (ISO 27001, SOC 2, PCI DSS, FCA SYSC).
Free Retests, Standard
Verify remediation of every finding before close-out. Letter of attestation for audit submission included. Most competitors charge £1,500-£3,000 per retest.
UK-Based CREST Testers
Every engagement performed by vetted, UK-based CREST-certified testers, matched to your needs, security clearance, and compliance scope.
FAQ
Frequently Asked
Do you test the API as well as the front end?
Yes, and it is where most findings come from. If the API is owned by another team we still test it through the application, and we say so in the scope.
We use Next.js. Is this the right page?
There is a dedicated Next.js page, because server side rendering, middleware and server actions change the test.
Do you need our repository?
No. We work from the deployed application. Source maps help but are not required, and if they are public that is a finding.
Is React less secure than a server-rendered application?
No, but the mistakes move. Server-rendered apps leak through templates, React apps leak through the API and the bundle.
Can you test a component library or design system?
Only as part of an application. On its own there is no authorisation boundary to test.
What about React Native?
That is a mobile test, which covers the bundle extraction and device storage that a web test cannot reach.
Our admin pages sit behind a route guard in React. Is that enough?
No. A client-side guard only changes what the interface shows. The browser still holds the code, and the API answers whatever request it receives. We call every admin endpoint with a standard user’s token and with no token, because the check has to live on the server.
We store the access token in localStorage. Is that a problem?
It raises the cost of any cross-site scripting bug. OWASP says not to keep session identifiers in local storage because any JavaScript on the page can read it, and a cookie with the httpOnly flag avoids that. We look for a way to run script in your app and test what the stolen token can reach. See the OWASP HTML5 Security Cheat Sheet.
We use dangerouslySetInnerHTML for CMS content. Is that a problem?
It is if the HTML is not trusted. The React documentation says that content based on user data risks a cross-site scripting vulnerability, and that the markup should come from a completely trusted source. We try script in every CMS field and user input that ends up in that prop. See the React documentation.
20+ CREST-accredited testing services in one place
Web, mobile, API, cloud, AI, infrastructure, red team. Pick the test that fits your environment.
Get your React application tested properly
Send us the application URL and the roles. You will have a fixed scope and a number within 24 hours.
