Ruby on Rails

`csrf-param` meta tags or the `rails-ujs` script in the markup — weight 70.

A cookie matching `_session_id` or containing `_rails` — weight 45, which only adds to the score.

The meta tags come from the `csrf_meta_tags` helper that standard Rails layouts include, which makes them the reliable signal.

Ruby is never inferred separately, and neither is the application server.

The security guide shows `csrf_meta_tags` producing `<meta name="csrf-param" content="authenticity_token">` together with the token itself.

Front-end code reads the token from these tags and sends it back with requests that change state.

Their presence is how Rails protects forms and script-issued requests; it is not a disclosure worth removing.

Because the token is per session, it should never appear in a response that a shared cache is allowed to store.

`config.force_ssl` forces all requests to be served over HTTPS and makes `https://` the default when Rails generates URLs.

Enforcement is handled by the `ActionDispatch::SSL` middleware, configurable through `config.ssl_options`.

The security guide states that the Strict-Transport-Security header is added to responses when `force_ssl` is enabled.

So a missing HTTP-to-HTTPS redirect and a missing HSTS header on a Rails site usually share one cause, and one fix.

It proves the layout uses Rails conventions.

It does not reveal the Rails version.

It does not identify the server in front of the application, which is where TLS may terminate — and where HTTPS enforcement can also be configured instead of in Rails.

A site may enforce HTTPS at a proxy with `force_ssl` off; the audit reports the behaviour, not which layer produced it.

`technology.inventory` lists the detection with its evidence.

`transport.http_redirect` and `transport.hsts` report the two behaviours `force_ssl` controls.

`cookies.secure` and `cookies.httponly` report the flags on the session cookie actually set.

`api.cache.policy` reports whether responses that carry per-user content are marked non-cacheable for shared caches.

The security guide lists headers Rails returns on every response by default.

`X-Frame-Options` is set to `SAMEORIGIN`, allowing framing on the same domain only.

`X-Content-Type-Options` is set to `nosniff`, and `X-Permitted-Cross-Domain-Policies` to `none`.

`Referrer-Policy` is set to `strict-origin-when-cross-origin`, which sends only the origin on cross-origin requests.

These are configured through `config.action_dispatch.default_headers`, so a Rails site missing them usually has that setting overridden — or a proxy stripping them.

Content-Security-Policy is not among the defaults and has to be configured.

The security guide states that Rails uses `CookieStore` as its default session storage, which keeps the session hash in a cookie on the client rather than a session ID.

It lists the consequences: cookies are limited to 4 kB, and the client may keep or copy cookie contents, so sensitive data does not belong in them.

It also warns about replay attacks with cookie-stored sessions, since an old cookie remains valid unless something server-side invalidates it.

Content-Security-Policy is configured in an initializer through a policy DSL, which is where a missing CSP on a Rails site is fixed.