Ruby on Rails Penetration Testing
Ruby on Rails penetration testing looks where the conventions were bent, because Rails does so much for you. One permit! or an unscoped find(params[:id]) hands a user another user’s records. CREST-certified testers, fixed price from £2,590 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.”
Strong parameters, CSRF tokens and escaped output come as standard, so the interesting findings are the exceptions. A controller that permits everything to make a form work. A model attribute that should never have been client controlled. An action that skips the before filter because it was easier during development.
Convention protects Rails applications until someone takes a shortcut
The failure modes are specific and repeatable. params.permit! in a controller that creates users. Project.find(params[:id]) with no current_user scope. A secret_key_base committed to the repository, so the session cookie can be forged. config.hosts left empty in production. A skip_before_action :require_login that covers more actions than it should.
The Rails security guide shows the risk: Project.find(params[:id]) lets a user change the id to 42 and read a project they may not see, where current_user.projects.find would refuse. And permit! allows all current and future model attributes to be mass assigned, so an admin or role field in the body is accepted. The Rails security guide covers the lookup.
We test it as one user against another. With two accounts we swap every ID on every route that takes one, post extra attributes such as role or admin to each create and update, send a forged Host header, and call actions that skip the login filter without a session. ISO 27001, SOC 2, PCI DSS and Cyber Essentials Plus audits accept manual penetration test evidence. Scan-only evidence is generally insufficient.
RAILS SPECIFICS
What We Actually Test in a Rails Application
Ten test areas that apply because the application is Rails, on top of the standard application checks. Every finding is verified, reproducible and mapped to OWASP, CWE and CVSS 3.1.
Strong parameters and mass assignment
Permitted attributes per controller, nested parameters, and fields such as role or account identifier accepted from the client.
Secret key base and sessions
Key strength and reuse, cookie store contents, session forging, and rotation after exposure.
Deserialisation
YAML and Marshal reached from request data, cache and job payloads, and serialised columns.
Active Record injection
Order, group, pluck and raw conditions built from parameters, and search or filter interfaces.
Authorisation
Policies and abilities not enforced on every action, nested resources, and scopes that filter by parameter rather than by user.
Rendering and templates
Inline rendering, dynamic template selection, and output marked as safe that should not be.
Redirects and callbacks
Redirects built from parameters, skipped before actions, and format handling that changes the code path.
Active Storage and uploads
Direct upload signing, content type handling, variant processing and public blob URLs.
Background jobs
Job dashboards published without authentication, and arguments that cross a trust boundary into the worker.
Gems and versions
Known issues in the installed gemset, unsupported Rails versions, and monkey patches that change framework behaviour.
METHODOLOGY
What a Rails 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.
Accept header manipulation returns arbitrary files from the application server
- Affected
- A Ruby on Rails application at [redacted] using dynamic template rendering on a dashboard action.
- What we found
- A crafted Accept header caused the view layer to treat a traversal path as a template name and return the file contents in the response. We retrieved the encrypted credentials file and the master key that decrypts it.
- Why it matters
- Disclosure of the master key, which unlocks every credential in the repository, including the production database password and the third party payment key.
- Fix
- Upgrade Rails, stop rendering templates from dynamic input, rotate the master key and all credentials it protected, and restrict the application user so it cannot read files outside its own directory.
Reconstructed from public research: CVE-2019-5418, file content disclosure in Action View.
Rails 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 Rails 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,590 for a small, single-scope engagement, agreed up front. Most engagements run £3,970 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 Rails 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
Rails 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 Rails 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 API-only Rails applications?
Yes. Those scope as API tests, where object level authorisation and parameter handling carry most of the risk.
Our Rails version is old. Is that a problem?
It is a reason to test. We will tell you which findings are fixed by upgrading and which are in your own code.
Can you test Hotwire or Turbo applications?
Yes. Turbo streams and frames are endpoints like any other, and we test what they return for each role.
Do you need the repository?
No. A code review is a separate service, and it is the better tool for deserialisation and gadget hunting.
Will you test Sidekiq or the admin dashboards?
Yes, when they are in scope. They are often reachable and often unauthenticated.
What about the database?
Injection paths are in scope. Database hardening sits with the internal infrastructure test.
We use permit! in a few controllers. Is that a problem?
It permits an entire hash without checking the values, and the Rails guide says it allows all current and future model attributes to be mass assigned. If the model has a role, admin or account_id column, a signed-in user can set it in the request. We post those attributes to every controller that calls it. See the Action Controller strong parameters section.
Our config.hosts is empty in production. Is that safe?
It is the default. Outside development, Rails.application.config.hosts is empty and no Host header checks are done. That means the Host header is trusted as sent, so we send requests with altered values and look at what the application builds from them, such as links and redirects. See the config.hosts documentation.
Our Active Storage service is set to public: true. Is that a problem?
By default Active Storage assumes private access and generates signed, single-use URLs. With public: true in config/storage.yml, blobs become publicly accessible. We check whether anything private, such as invoices or identity documents, is stored on a public service. See the Active Storage public access section.
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 Rails application tested properly
Send us the application and the roles. You will have a fixed scope and a number within 24 hours.
