How do you implement secure coding practices in Ruby?

Long Answer

Implementing secure coding in Ruby means treating every boundary as hostile, every dependency as potential risk, and every output as a possible vector. The objective is layered defense: prevent injection, contain damage, and continuously verify trust. Below is a pragmatic blueprint.

1) Input validation and sanitization

Start with whitelist validation (allow known-good) rather than blacklist (block known-bad). For forms and APIs, enforce types, formats, and ranges (e.g., integers, enums, RFC-compliant emails). Normalize inputs (trim, downcase where safe) before checks. For HTML, sanitize using trusted libraries; for file uploads, inspect MIME types and size limits, store outside web roots, and generate random filenames. Treat HTTP headers and environment variables as untrusted.

2) Output encoding and template safety

Injection often succeeds at rendering time, not input time. Always encode on output in the correct context: HTML, attribute, URL, or JavaScript. Use template engines (ERB/HAML/SLIM) with auto-escaping defaults and only allow explicit unescape where audited. When building URLs or query strings, use standard encoders to avoid open redirects and XSS in parameters.

3) SQL injection prevention

Never string-concatenate SQL. Use parameterized queries via Active Record relations or prepared statements. For dynamic ORDER BY or column names, map user-provided values to a safe, static whitelist. Avoid raw where("...#{param}..."); prefer where(column: value) or sanitized fragments. For reporting queries, wrap raw SQL in vetted scopes and limit risky features like multi-statement execution.

4) Command and OS interaction

When shelling out, prefer system(cmd, *args) or Open3.capture3 with array arguments, not single-string interpolation. Validate executable paths and user-provided arguments against allowlists. Drop privileges for spawned processes. For file operations, canonicalize paths and prevent directory traversal by rejecting .. segments and absolute paths when not expected.

5) Deserialization and unsafe object loading

Avoid Ruby’s Marshal.load and YAML.load on untrusted data; both can instantiate arbitrary objects. Prefer JSON.parse on strict schemas, use YAML.safe_load with permitted classes if YAML is unavoidable, and sign or MAC any serialized payload using HMAC. For session stores, do not trust client-controlled serialized objects; keep server-side sessions or encrypt/sign cookies with rotation.

6) Dependency management and supply chain

Pin versions in Gemfile.lock, use semantic versioning policies, and run dependency scanners in CI. Remove unused gems, prefer well-maintained libraries, and avoid eval-heavy or meta-programming-heavy gems without review. Configure a private gem mirror if possible and enable checksums/signatures. Automate updates with tools that open PRs plus SAST/DAST gates.

7) Secrets, configuration, and crypto hygiene

Never hardcode secrets. Use environment variables or encrypted credentials. Rotate keys regularly, scope them minimally, and audit their usage. Use proven crypto (AES-GCM, SHA-256 HMAC) via high-level libraries; never roll your own. For password storage, choose modern hashers (bcrypt/argon2) with per-user salts. Enforce TLS everywhere; validate certificates in outbound calls.

8) Web protections: CSRF, headers, CSP

Enable CSRF protection for state-changing requests. Set security headers: HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy. Add a Content Security Policy (CSP) that defaults to self, tightens script sources, and uses nonces. Serve static assets from controlled origins with subresource integrity where applicable.

9) Authorization and least privilege

Centralize authorization checks; do not scatter inline conditionals. Enforce least privilege at DB (read-only users for read paths), filesystem, and network egress. For background jobs, restrict what arguments they accept and validate IDs against ownership rules.

10) Testing, CI, and monitoring

Security is continuous. Add SAST linters, gem vulnerability scans, and dependency diff alerts. Write security unit tests for validations and encoders. Include integration tests that verify injection defenses (e.g., payloads in feature specs). In production, monitor for spikes in 4xx/5xx, anomalous paths, and WAF alerts. Log with context and correlation IDs, redacting PII by default.

By weaving these practices—contextual encoding, strict validation, safe deserialization, minimal and pinned dependencies, and automated verification—secure coding in Ruby becomes routine, not exceptional. Fail closed, log intentionally, and keep the attack surface small.

‍

Table

‍

Common Mistakes

• Concatenating SQL or shell strings directly with user input.
  
• Validating input but forgetting contextual output encoding (e.g., JS string vs HTML).
  
• Using Marshal.load or YAML.load on external data.
  
• Trusting third-party gems without pinning or scanning; leaving transitive vulns.
  
• Storing secrets in repo or logs; no rotation.
  
• Disabling CSRF “temporarily,” then forgetting to re-enable.
  
• Overbroad CSP that allows unsafe-inline scripts permanently.
  
• Logging full request bodies with PII, creating compliance and breach risks.
  
  

Sample Answers

Junior:
“I validate inputs and escape outputs in views. I use parameterized queries instead of building SQL strings. I avoid unsafe deserialization and prefer JSON. I keep gems updated and do not commit secrets.”

Mid:
“My approach enforces whitelist validation and context-aware encoding. SQL uses prepared statements, and shell calls use array arguments. I replace YAML.load with YAML.safe_load and sign any serialized data. CI runs gem vulnerability scans and SAST. We enable CSRF, CSP, and HSTS by default.”

Senior:
“I standardize a security baseline: validation + output encoding, parameterized DB access, safe deserialization, and least privilege. Supply chain is controlled via pinned gems, scanners, and PR-based updates. Secrets are rotated, crypto uses vetted libraries, and CI gates enforce policies. We test for injections, monitor anomalies, and run post-incident reviews to harden patterns.”

‍

Evaluation Criteria

Look for defense-in-depth: input validation plus contextual output encoding; parameterized SQL and safe shell usage; strict deserialization policies; pinned, scanned dependencies; secrets hygiene; and browser-layer controls (CSRF, CSP, HSTS). Strong answers mention mitigating injection and deserialization attacks explicitly and describe automation in CI (SAST, dependency scans). Red flags: concatenated SQL, Marshal.load on untrusted data, secrets in code, or reliance on framework defaults without understanding contexts. Senior candidates should connect policy to tooling, monitoring, and continuous hardening.

‍

Preparation Tips

• Practice input validation patterns and output encoding per context (HTML, URL, JS).
  
• Rewrite raw queries into parameterized forms; add tests with malicious payloads.
  
• Replace unsafe deserialization with JSON + schema validation; learn YAML.safe_load.
  
• Audit Gemfile.lock; remove abandoned gems; set up scanners and update bots.
  
• Configure CSRF, CSP, HSTS, and security headers; tune CSP nonces.
  
• Implement encrypted credentials and key rotation; test secret rollover.
  
• Add SAST and dependency checks to CI; fail builds on critical issues.
  
• Build a small “attack lab” to safely test payloads and verify defenses.
  
  

Real-world Context

A marketplace app eliminated XSS by switching to strict context-aware encoding and a tuned CSP with nonces; incident tickets dropped. A fintech removed YAML.load from webhooks, moved to JSON with signatures, and stopped deserialization exploits. A SaaS trimmed 25% of gems, pinned the rest, and added CI scans; a transitive vuln was caught before release. Another team rotated credentials quarterly, preventing an exfiltration attempt from granting long-lived access. These cases show that secure coding in Ruby is not theoretical—it measurably reduces incidents and audit findings.

‍

Key Takeaways

• Validate inputs and encode on output per context.
  
• Use parameterized SQL and safe shell APIs to block injection.
  
• Replace unsafe deserialization; prefer JSON + schemas and signed payloads.
  
• Pin and scan gems; remove abandoned dependencies.
  
• Enforce CSRF, CSP, HSTS, and secret rotation.
  
• Automate security checks in CI and monitor production for anomalies.
  
  

Practice Exercise

Scenario:
You are adding a “custom reports” feature that accepts filters from users and generates CSV downloads. Security must block injection, deserialization attacks, and data leakage.

Tasks:

1. Input validation: Implement strict types and allowlists for filter fields (status, from, to, sort_by). Reject unknown fields and invalid ranges.
   
2. SQL safety: Convert all queries to parameterized Active Record calls. For sort_by, map to a fixed hash { "created_at" => "created_at", "amount" => "amount" }; reject others.
   
3. Output encoding: Ensure CSV escaping of delimiters and quote fields correctly; sanitize header names.
   
4. Deserialization: Replace any serialized filter storage with JSON; validate against a schema; sign payloads server-side if persisted.
   
5. Dependencies: Audit Gemfile.lock, remove unused gems, pin versions, and enable dependency scanning in CI.
   
6. Web protections: Verify CSRF on POST endpoints; set CSP and HSTS; add safe download headers.
   
7. CI checks: Add tests with malicious payloads ("1; DROP TABLE", "<script>", YAML objects). Fail the build on any unescaped output or SQL interpolation.
   
8. Monitoring: Log blocked attempts with redaction and correlation IDs; create dashboards and alerts on spikes.
   
   

Deliverable:
Code diffs, tests, and a security note explaining how validation, parameterization, safe serialization, and CI checks together implement secure coding in Ruby for this feature.