SvelteKit Penetration Testing
In SvelteKit an auth check only protects the file it sits in, and form actions run before load functions. We test every hook, action and endpoint for gaps. CREST-certified testers, fixed price from £2,520 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.”
SvelteKit runs hooks.server.js, page load functions and form actions in a fixed but non-obvious order, and an auth check placed in the wrong one of those three never fires before the request it was meant to guard. We test what actually runs before each route, action and endpoint you have, not what the file structure implies protects it.
Why a SvelteKit auth check only works in the file it actually runs in
Every request to a SvelteKit application passes through hooks.server.js first. SvelteKit’s own hooks documentation describes the handle function populating event.locals with whatever your app attaches there, a cookie lookup, a decoded token, a session record, and that same locals object is what +server.js handlers and every server load function read afterwards. We test whether the check your application actually depends on lives here, in the one place guaranteed to run before every route, or whether it was left for a load function or an action to enforce instead.
SvelteKit’s load functions documentation is explicit that a layout load function does not run on every request, client-side navigation between child routes can skip it, and an auth guard placed in +layout.server.js only protects a child page if that page calls await parent() before running its own protected code. Form actions add a second gap on top of that: SvelteKit’s guidance on actions confirms that a page’s load functions run after the action completes, not before, so an auth check written into any load function, layout or page, has already missed a form action that ran and took effect first. We test every layout, page, action and +server.js endpoint in scope against what actually runs before it, not what the parent route implies is protected.
The same file-based structure extends to secrets and static output. A variable exposed through $env/static/public ends up compiled into the client bundle, a server-only module has to be named with a .server suffix or placed in $lib/server before SvelteKit’s own import checks will catch a leak, and a route marked for prerendering is generated once at build time rather than checked on every visit. We test whether the boundary your team drew between public and private, and between build-time and per-request, actually holds for the specific routes, modules and pages in your SvelteKit application.
SCOPE
What we pen test on a SvelteKit application
hooks.server.js Handle and Locals Population
SvelteKit calls the handle function in hooks.server.js on every request, and whatever it attaches to event.locals is what +server.js handlers and every server load function read afterwards. We test whether the authentication or authorisation check your application actually depends on lives inside handle, the one place guaranteed to run before every route, action and endpoint in scope.
Layout load Functions and Requests That Skip Them
SvelteKit’s own documentation states that a layout load function does not run on every request, including client-side navigation between child routes, so an auth guard placed only in +layout.server.js can be bypassed simply by how the user navigated. We test every child route reachable under a guarded layout for the specific case where that gap leaves protected data reachable.
await parent() Dependency for Layout-Level Guards
Putting an auth check in +layout.server.js only protects a child page if that page’s own load function calls await parent() before running its protected code, a dependency SvelteKit’s load functions documentation states outright. We test whether every child route under a guarded layout actually calls await parent() first, rather than assuming the parent’s check reaches it automatically.
Form Actions Running Ahead of Any Load-Based Check
A form action defined in +page.server.js, default or named, runs and takes effect before that page’s load functions run again, so an authorisation check written only into a load function, whether on the page or a parent layout, has no chance to stop the action it was meant to guard. We test every default and named action in scope for an access check of its own.
+server.js Endpoint Authorisation
A +server.js file exposes its own GET, POST or other method handlers as a raw endpoint, entirely separate from any page’s load functions, so an auth check that only exists inside a +page.server.js load never reaches it. We test every +server.js route in scope for an authorisation check of its own, matched to the guard hooks.server.js actually applies to it.
Data Exposure from Server load Functions
A server load function’s return value has to be serialisable for transport to the browser, and SvelteKit sends that entire payload to the client regardless of which fields the page component actually renders. We test every +page.server.js and +layout.server.js load function for fields returned to the client beyond what the visible page needs, including data meant for a different role or record.
$env/static/private and $env/static/public Boundary
$env/static/private cannot be imported into client-side code and only carries variables that do not start with the public prefix, while $env/static/public is bundled into client-side JavaScript and only carries variables starting with that prefix, default PUBLIC_. We test for a secret assigned the public prefix by mistake, and for any value your application needs client-side that was moved to the wrong module to make it compile.
Server-Only Module Boundaries
SvelteKit only protects a module from being bundled into client-side code once it is named with a .server suffix or placed inside $lib/server, and it errors if public-facing code imports it, even indirectly through another module. We test for secrets, database clients or internal logic kept in an ordinary module outside those two locations, where that protection never applies.
CSRF Origin Checking Configuration
SvelteKit’s checkOrigin setting compares the incoming Origin header against the server’s own origin for POST, PUT, PATCH and DELETE requests carrying form-encoded, multipart or plain text bodies, and trustedOrigins lists any origin allowed to bypass that check. We test whether checkOrigin has been disabled or trustedOrigins widened further than the third parties your application actually needs to accept submissions from.
Prerendered Pages and Build-Time Output
A route marked export const prerender = true is generated once at build time and served as a static file, so any per-request authorisation check inside it never runs again for a real visitor. We test every prerendered page and +server.js route in scope for content that should have depended on who is asking, rather than being baked into a file served to everyone.
OUR PROCESS
SvelteKit Penetration Testing: From Scope to Attestation
Scope and Route Mapping
We agree the environments, routes and deployment adapter in scope, and map every hooks.server.js file, +page.server.js load function, form action and +server.js endpoint against the auth checks your application depends on.
Hook, Load and Action Review
We review what actually runs in hooks.server.js handle, which load functions are universal versus server-only, and which form actions and endpoints an auth check placed in a parent layout does not reach.
Manual Exploitation
A CREST-certified tester manually tests hook, load and action coverage, data returned by load functions, and CSRF and environment variable configuration, chaining findings 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 SvelteKit 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 SvelteKit 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 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 quoteSECTORS
Sectors We Test SvelteKit 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 SvelteKit 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 SvelteKit application?
We need at least one authenticated account for every distinct role or permission level your application defines, plus a valid session cookie or token for each guard combination hooks.server.js and your load functions apply. Sight of your route structure, or which files are +page.server.js, +server.js and hooks.server.js, speeds up mapping every load function, form action and endpoint in scope.
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 deletes and any outbound emails or webhooks your form actions and endpoints would normally trigger, and we do not run destructive tests against real customer records without that agreement in writing.
How long does a SvelteKit penetration test take?
A single SvelteKit 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 larger set of form actions and endpoints, or a separate backend API moves into a larger scope with more testing days.
Does the adapter we deploy with change what you test?
No. Whether you deploy with adapter-node, adapter-vercel, adapter-cloudflare, adapter-netlify or another target, the hooks, load functions, form actions and endpoints we test are the same application code. Where a route is fully static output from adapter-static, there is no server runtime behind it, so testing that route is scoped to what actually ships in the client bundle.
Are prerendered pages included in the test?
Yes. We check every route marked export const prerender = true or ‘auto’ for content that depended on a per-request check that only ran once at build time, and for anything baked into that static file that should have been specific to the person requesting it.
What is out of scope for a single-framework SvelteKit test?
Infrastructure-level issues in the underlying server, container platform or cloud configuration are out of scope for this test and covered by our cloud penetration testing service instead. A separate backend API consumed by your SvelteKit frontend, built in a different framework or language, 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 hooks.server.js, load functions, form actions and server-only modules alongside testing, is available if you want faster or deeper coverage of specific findings.
Does SvelteKit have a customer penetration-testing policy we need to follow?
No. SvelteKit 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 directly. If your application runs on a managed hosting or edge platform such as Vercel, Cloudflare or Netlify, that provider’s own penetration-testing policy still applies, and we confirm its current terms with you during scoping.
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 SvelteKit application
In SvelteKit an auth check only protects the file it sits in, and form actions run before load functions. We test every hook, action and endpoint for gaps. CREST-certified testers, fixed price from £2,520 for a 2-day single-framework scope, quoted within 24 hours.
