ruby-on-rails-idor-forcing-json-responses-to-spot-leaks
Ruby on Rails IDOR: forcing JSON responses to spot leaks
When testing IDOR / Broken Access Control on a Rails app, the HTML page such as /users/1 often hides fields via the view layer, but the same controller action may also support API-style responses that return raw model data. If access control is weak, requesting JSON can expose sensitive attributes you’d never see in HTML.
Why this works in Rails
Rails controllers commonly use content negotiation (responding differently based on format):
- Path format:
GET /users/1.json - Accept header:
Accept: application/json
If the action renders render json: @user (or uses serializers poorly), Rails may include fields like email, password_digest/hash, internal IDs, timestamps, links, roles, etc.
Ways to request JSON instead of HTML
1) Extension-based format
<strong>GET /users/1.json HTTP/1.1
</strong>Host: target
2) Accept header negotiation
GET /users/1 HTTP/1.1
Host: target
<strong>Accept: application/json
</strong>
Both can result in:
Content-Type: application/json; charset=utf-8- A JSON body with more fields than the HTML view
When testing for IDOR (Insecure Direct Object Reference) vulnerabilities in Ruby on Rails applications that use scaffolding, always try endpoints like /files/4/edit (with the /edit part included). By default, the scaffold generator enables these edit actions without any built-in authorization checks on the resource ownership.