Nuxt Penetration Testing
Nuxt renders on the server and sends the result to the browser, private data included if you let it. We test server routes, runtime config and page payloads. CREST-certified testers, fixed price from £2,380 for a 2-day single-framework scope, quoted within 24 hours.
- Unlimited retesting
- Unlimited pre-retesting
- No hidden fees
“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.”
Nuxt runs the same components and composables on the server and in the browser by design, and by default forwards whatever the server rendered, including fetched data, into the page. We test what actually reaches the browser, not just what your interface chooses to show afterwards.
Why Nuxt security depends on what crosses from server to browser
Nuxt’s server/ directory turns files into API endpoints directly: a file at server/api/orders.get.ts becomes a GET handler for /api/orders, and each one is built with h3’s defineEventHandler as an independent function. Nuxt’s own server directory documentation confirms that anything placed in server/middleware runs before every server route to inspect or extend the request, commonly by setting a value such as event.context.auth, but it must not close or respond to the request itself. That leaves the actual authorisation decision to each individual handler, so we test whether every server/api and server/routes handler in scope actually checks the context your middleware set, rather than assuming a request that reached it is already authorised.
Nuxt splits configuration into private keys, available only on the server, and a nested public object that ships to the browser, and Nuxt’s runtime config documentation lets either half be overridden at deploy time through matching NUXT_ and NUXT_PUBLIC_ environment variables. The same page carries its own warning against exposing a private key to the client by rendering it or passing it to useState, and we test every runtime config key in scope against that exact boundary: what is declared public, what an environment variable can override, and whether anything meant to stay on the server has found its way into a component, a template or a piece of shared state.
Because Nuxt runs the same code on the server and in the browser, useFetch and useAsyncData forward whatever a server-side call returns into the page payload so the client does not fetch it again on hydration, a mechanism Nuxt’s own data-fetching guide describes as visible in the DevTools payload tab. Route middleware sits on top of this and only ever runs within the Vue part of the application, guarding page navigation, not the underlying server route a page calls, which is a completely separate system built on Nitro. We test what a page’s server-side data calls actually return against who is allowed to see it, and whether the server route behind a protected page enforces that itself rather than trusting the page-level guard in front of it.
SCOPE
What we pen test on a Nuxt application
Server Route Authorisation Inside Each Handler
Every file in server/api and server/routes is built with h3’s defineEventHandler as its own standalone function, and Nuxt does not attach a shared guard to that handler unless your code wires one in. We test every server route in scope for an authorisation check inside the handler itself, not an assumption that something upstream already covered it.
Server Middleware Context Versus Enforcement
A file in server/middleware runs before every other server route and can inspect or extend the request, such as setting event.context.auth, but Nuxt’s documentation is explicit that middleware must not close or respond to the request itself. We test whether every handler that depends on that context actually reads and enforces it, rather than treating the middleware’s presence as protection on its own.
Route Middleware Guards Pages, Not the API Behind Them
Route middleware, anonymous, named or global, runs entirely within the Vue part of a Nuxt application to control page navigation, and Nuxt’s own documentation describes it as a completely separate system from server middleware, which runs in Nitro. We test whether the server route a protected page calls enforces its own authorisation, since a request sent straight to that route bypasses the page-level guard in front of it, the same boundary we test on a Vue.js frontend.
Public and Private Runtime Config Boundaries
runtimeConfig keys stay private to the server unless nested under public, and Nuxt lets either half be overridden at deploy time through matching NUXT_ and NUXT_PUBLIC_ environment variables. We test every runtime config key in scope against what is actually declared public and what your application needs to keep on the server, and whether a deploy-time environment override has moved a value across that line.
Config or Secrets Reaching the Client via Rendering or useState
Nuxt’s own runtime config documentation warns against exposing a private key to the client by rendering it in a template or passing it into useState, since a useState value is serialised to JSON and shared across the application once set. We test components and composables in scope for exactly that pattern, a server-only value that ends up inside client-visible state.
useFetch and useAsyncData Payload Exposure
useFetch and useAsyncData forward whatever a server-side call returns into the page payload so the browser does not refetch it on hydration, and that payload is plain data visible in the rendered page and inspectable through the Nuxt DevTools payload tab. We test what each server-side data call actually returns against what the requesting user or role should be allowed to see, since anything forwarded that way has already reached the browser before a client-side check runs.
Catch-All and Method-Suffixed Server Routes
A file such as server/api/foo/[…].ts registers a catch-all handler for any unmatched path under it, and pairing method-suffixed files, such as test.get.ts alongside test.post.ts, is what makes any other verb against that path return a 405 rather than reaching application code. We test every catch-all and dynamic route for what event.context.params actually resolves to, and every write-capable endpoint for a method-suffixed handler that enforces the verb your application intends.
Prerendered and Cached Routes Serving Fixed Output
Nuxt’s route rules can mark a path as prerender to bake it into a static file at build time, or apply swr or isr to cache a full server response for a set period, and Nuxt registers the caching automatically once a rule is set. We test every prerendered or cached route in scope for data that should vary by user or role, since a route rendered once and served from a static file or cache returns the same content to everyone who requests it until the next build or cache expiry.
Session State Set on the Server, Read Differently in the Browser
Nuxt runs the same components and composables on the server and in the browser, but request-scoped values such as event.context are only ever available on the server, so the browser has to obtain the equivalent authentication state some other way, typically the payload, a cookie or a follow-up API call. We test whether that client-side representation of who is logged in can be manipulated independently of the server-side session that actually authorises requests.
Shared Server Utilities and Storage Across Every Handler
Helpers placed in server/utils are auto-imported into every server route, middleware and plugin, and Nitro’s storage layer, reachable through useStorage, is shared across the whole server rather than scoped to one handler. We test whether a permission-check utility is applied consistently everywhere it is imported, and whether a storage key used by one feature can be read or overwritten by another.
OUR PROCESS
Nuxt Penetration Testing: From Scope to Attestation
Scope and Access
We agree the environments, server routes and any accounts or roles we need, plus which parts of the Nuxt application, such as a connected CMS or third-party auth, sit in or out of scope.
Runtime Config and Route Mapping
We map every server/api and server/routes handler in scope against its middleware, and every runtimeConfig key against what your application declares public and what an environment variable can override.
Manual Exploitation
A CREST-certified tester manually tests server route authorisation, runtime config boundaries and payload exposure, chaining findings across pages, server routes and any prerendered or cached output where they compound.
Attestation and Retest
You get a technical report with CVSS scores and reproduction steps, a walkthrough call, a free retest once fixes are deployed, and an attestation letter for auditors.
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 Nuxt 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 £3,500 for a single-role, single-app scope, agreed up front. Most engagements run £5,000 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 written so your team can reference the report against each framework 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 Nuxt Penetration Testing Pricing
Pricing depends on the number of roles, integrations and environments in scope. See our pricing page for how we quote.
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 4 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 quoteSECTORS
Sectors We Test Nuxt For
Sector-specific scoping for regulated UK organisations.
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 Nuxt 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
What access do you need to test our Nuxt application?
We need at least one authenticated account for every role or permission level your application exposes, plus access to the environments in scope, whether that is server routes served from server/api, server/routes, or both. If the application calls a database, CMS or third-party API from the server side, tell us during scoping so we can agree what those calls are allowed to touch.
Will testing touch our live data?
We test whichever environment you give us access to. If that is production, we agree exclusions upfront, such as bulk writes and any outbound calls your server routes would normally trigger, and we do not run destructive tests against real customer records without that agreement in writing.
How long does a Nuxt penetration test take?
A single Nuxt application sits in our 2-day single-framework scope, with a report typically landing around 5 working days after kickoff. An application with a wider role matrix, a large server/api surface or several connected services moves into a larger scope with more testing days.
Do you test Nuxt applications deployed as static output as well as server-rendered ones?
Yes. Where routes are prerendered or cached through route rules, we test what has been baked into that output for data that should not be public, alongside the server-rendered routes running through Nitro.
What is out of scope for a single-framework Nuxt test?
Infrastructure-level issues in the underlying hosting platform, container setup or cloud configuration are out of scope for this test and covered by our cloud penetration testing service instead. A separate backend API your Nuxt application only consumes, rather than the one built into its own server/ directory, is also scoped and quoted separately.
Do you need our source code?
No. Testing is black-box against the running application by default. A grey-box option, where we review the relevant server routes, middleware and runtime config values alongside testing, is available if you want faster or deeper coverage of specific findings.
Does Nuxt have a customer penetration-testing policy we need to follow?
No. Nuxt is framework code you deploy and control yourself rather than a shared multi-tenant service, so there is no vendor notification process to follow before testing it. If your Nuxt application runs on a shared hosting or edge platform, that provider’s own penetration-testing policy still applies, and we confirm its current terms with you during scoping.
Is our API covered if it sits inside the same Nuxt project as the frontend?
Yes, where it is in scope. Any API built through server/api or server/routes is tested the same way as the rest of the application, including its own authorisation, validation and method coverage, regardless of whether the frontend calls it as REST or wraps it with GraphQL.
20+ CREST-accredited testing services in one place
Web, mobile, API, cloud, AI, infrastructure, red team. Pick the test that fits your environment.
Get a fixed price for your Nuxt application
Nuxt renders on the server and sends the result to the browser, private data included if you let it. We test server routes, runtime config and page payloads. CREST-certified testers, fixed price from £2,380 for a 2-day single-framework scope, quoted within 24 hours.
