---
title: "Security"
description: "181 posts about Security, summarised, each linking to the original."
---

# Security
> 181 posts about Security, summarised, each linking to the original.

## Articles

### [You should know about Server-Side Request Forgery](https://yomu.fyi/post/you-should-know-about-server-side-request-forgery.md)
- Company: [Fly.io](https://yomu.fyi/company/fly-io.md)
- Published: Feb 5, 2021
- Type: Tutorial

Server-side request forgery (SSRF) lets attackers make an application server issue HTTP requests, potentially reaching internal resources behind its security perimeter and taking over the hosting environment. The post describes two common patterns—user-supplied URLs and user data incorporated into URLs—and presents Smokescreen, an egress proxy, as a mitigation. Smokescreen checks that requested IP addresses are publicly routed, blocking private IPv4 ranges and IPv6 ULA space, while ACL actions can open, report, or enforce traffic rules. The Fly modification authenticates clients with a shared PROXY\_PASSWORD, maps authenticated requests to an authed role, and includes deployment instructions for Fly and Docker plus Go and Node.js examples that send authenticated HTTPS requests through the proxy.


### [Managing Google Cloud Platform Project-Wide SSH Keys](https://yomu.fyi/post/managing-google-cloud-platform-project-wide-ssh-keys.md)
- Company: [Shopify](https://yomu.fyi/company/shopify.md)
- Author: 2023-10-18
- Published: Jan 27, 2021
- Type: Problem & solution

Google Cloud project-wide SSH keys can remain in project metadata indefinitely after a user connects to a VM, potentially allowing matching private-key holders to access Linux VMs with root access unless project-wide keys are blocked. Shopify developed SSH-Pruner because OS Login did not work with Google Kubernetes Engine, while deleting all keys also removed Google’s keys, disrupted scripts, and created slow metadata updates. The new Go application uses Google Cloud APIs to find organization projects with Compute Engine enabled, reads the “ssh-keys” metadata, parses entries, retains unexpired keys, writes pruned common instance metadata, and records readable logs; Google-managed “sshKeys” entries are skipped. SSH-Pruner was already running as a cron job on some projects, with a slow rollout planned to limit workflow disruption.


### [How Shopify Uses WebAssembly Outside of the Browser](https://yomu.fyi/post/how-shopify-uses-webassembly-outside-of-the-browser.md)
- Company: [Shopify](https://yomu.fyi/company/shopify.md)
- Author: 2023-10-18
- Published: Dec 18, 2020
- Type: Explainer

Shopify describes using WebAssembly (Wasm) outside the browser to run untrusted Partner code on its own infrastructure, reducing partners’ need to operate scalable web services and avoiding network latency for time-sensitive customizations. Wasm provides a sandboxed, stack-based environment with explicit host imports, protected call stacks, and runtime type checking, while targeting near-native performance and multiple source languages. Shopify wraps Fastly’s open-source Lucet runtime and compiler in a Rust web service called the Wasm Engine, which manages module I/O and storage and applies results during runtime processes such as web requests. In a test executing 100,000 modules per minute for roughly five minutes, Lucet execution hovered around 100 μs and total p99 execution time was about 4 ms. Shopify selected AssemblyScript, with TypeScript-like syntax, for first-class developer support and is extending its tooling, SDKs, monitoring, and language support.


### [Vouching for Docker Images](https://yomu.fyi/post/vouching-for-docker-images.md)
- Company: [Shopify](https://yomu.fyi/company/shopify.md)
- Author: 2023-10-18
- Published: Dec 1, 2020
- Type: Explainer

Kubernetes does not enable Docker image signature verification by default, leaving organizations to decide whether images are trusted before they run in a cluster. The post explains code signing through hashes and public/private keys, then describes Binary Authorization as a combination of metadata storage, an enforcer, and a signing service. Using Grafeas and Kritis, or GKE’s Binary Authorization, cluster policies require specified attestors to sign images; invalid or unsigned images are blocked before their containers start. Voucher supplies the missing signing component as a REST service running in Cloud Run or Kubernetes: build pipelines submit image paths, Voucher performs security checks, signs qualifying images, and records signatures in the metadata service. Its extensible checks can verify internal ownership, GitHub commits, approvals, builder identity, and vulnerability counts, while distinct cluster policies balance compliance requirements with faster experimentation; Voucher later moved into the Grafeas organization.


### [More Fly Answers To Questions](https://yomu.fyi/post/more-fly-answers-to-questions.md)
- Company: [Fly.io](https://yomu.fyi/company/fly-io.md)
- Published: Sep 2, 2020
- Type: Explainer

This Q&A addresses three operational questions about Fly: running non-HTTP applications, identifying connection IP ranges, and renaming applications. Non-HTTP apps need a network service for Fly’s default TCP or optional HTTP health checks; otherwise, Fly may kill them, although Worker process support is planned. For connectivity controls, Fly says AS40509 ranges may not match source addresses seen by servers and advises treating Fly IPs as changeable, while client certificates over TLS offer improved authentication. Future IPv6 per-application addresses could support firewall allowlists. Renaming currently requires creating a new app with flyctl init, claiming the desired name, changing fly.toml, redeploying, and manually restoring secrets, certificates, hostnames, scaling, regions, and other configuration, while sacrificing the original app’s history.


### [Sandboxing and Workload Isolation](https://yomu.fyi/post/sandboxing-and-workload-isolation.md)
- Company: [Fly.io](https://yomu.fyi/company/fly-io.md)
- Published: Jul 29, 2020
- Type: Explainer

Workload isolation makes it harder for a vulnerability in one service to compromise the rest of a platform, and becomes especially important when hosting other people’s code. The post surveys isolation mechanisms from chroot and privilege separation through namespaced containers, mandatory access control, seccomp-bpf, capabilities, and language runtimes, before considering virtualized approaches. It emphasizes that network exposure is often the most consequential attack surface, while chroot alone leaves access to ptrace, procfs, device nodes, and networking. Firecracker is presented as the selected VMM: a small Rust implementation that limits itself with seccomp-bpf and runs under an external jailer providing chroot, namespaces, and dropped privileges. The closing menu includes nsjail, unprivileged Docker with tighter filtering, gVisor, and Firecracker or Kata; absent hostile code, the author would tune nsjail for return on investment.


### [Bug Bounty Year in Review 2019](https://yomu.fyi/post/bug-bounty-year-in-review-2019.md)
- Company: [Shopify](https://yomu.fyi/company/shopify.md)
- Author: 2023-10-18
- Published: Feb 6, 2020
- Type: Announcement

Shopify’s 2019 bug bounty review describes experiments and process improvements intended to increase program speed, while reporting changes in response, resolution, disclosure, and bounty metrics. Shopify-Experiments, a private program launched in mid-2019 for high-signal, high-impact hackers, tested expanded scope, full payment after triage, disclosure requirements, self-closing false positives, and collaboration with third-party developers. Using registration data, HackerOne API exports, and a Slack chatbot, the team improved program analytics and automated report-state changes, assignments, comments, bounty suggestions, and common invalid-report closures. Average first response fell to 16 hours, triage to 2 days and 13 hours, bounty payment to 7 days and 1 hour, and post-triage resolution to 20 days and 3 hours; disclosures rose to 74 bugs. For 2020, Shopify announced full bounty payment within seven days of triage, a $50,000 maximum bounty, higher payouts for several vulnerability classes, and added visibility for duplicate reports.


### [Chrome’s Changes Could Break Your App: Prepare for SameSite Cookie Updates](https://yomu.fyi/post/chrome-s-changes-could-break-your-app-prepare-for-samesite-cookie-upda.md)
- Company: [Heroku](https://yomu.fyi/company/heroku.md)
- Author: Lenora Porter
- Published: Feb 4, 2020
- Type: Tutorial

Chrome's SameSite changes alter when third-party cookies are sent in cross-site requests, affecting sites that rely on embedded services, analytics, advertising, or other cross-domain functionality. Starting February 4, 2020, Chrome was to reject such cookies unless they were secured and assigned an appropriate SameSite value, as part of a secure-by-default model intended to reduce CSRF attacks, other vulnerabilities, and privacy leaks. The post explains first- versus third-party cookies, contrasts Strict, Lax, and None, and gives scenarios for selecting each setting; SameSite=None must be paired with Secure and HTTPS. It also recommends enabling Chrome 80 flags to test for errors, then updating application cookies or coordinating with third-party providers. Server-side support is noted for PHP, NodeJS, Python, Flask, and Ruby on Rails, with direct JavaScript cookie handling also mentioned.


### [Building Shopify’s Application Security Program](https://yomu.fyi/post/building-shopify-s-application-security-program.md)
- Company: [Shopify](https://yomu.fyi/company/shopify.md)
- Author: 2023-10-18
- Published: Apr 26, 2019
- Type: Explainer

Shopify's application security program is designed to preserve safety while products and services scale quickly across a platform serving more than 800,000 merchants. It organizes the work around scaling secure applications, scaling security teams, and scaling security interactions, with a culture that treats security as a non-negotiable priority. Standardizing on Ruby on Rails and other shared technologies lets tooling go deep, while service tracking provides visibility into applications, dependencies, code, and automated dependency updates. The security organization grew from one employee into specialized teams, supplemented by penetration testing, bug bounties, and audits, while incident response remains shared across the company. At the code level, tripwires detect dangerous patterns early; Shopify renamed html\_safe to dangerously\_output\_as\_html, links flagged pull requests to XSS training, and alerts Application Security, shifting review toward automation.


### [One Million Dollars in Bug Bounties](https://yomu.fyi/post/one-million-dollars-in-bug-bounties.md)
- Company: [Shopify](https://yomu.fyi/company/shopify.md)
- Author: 2023-10-18
- Published: Apr 3, 2019
- Type: Announcement

Shopify announces that it has awarded more than $1M USD through its bug bounty programs, which complement its security strategy by bringing in researchers with varied perspectives to assess the platform. The company says it is the fifth public program among 176 on HackerOne to reach that milestone, after four years of working with researchers. It describes three resolved vulnerabilities: an SSRF in Shopify Exchange that could provide root access within one infrastructure subset, an admin authentication bypass involving duplicate partner accounts, and stored cross-site scripting from improperly sanitized sales-channel SVG files. Shopify disabled or audited affected services, deployed a metadata-concealment proxy, corrected account verification, removed unnecessary admin functionality, and checked for exploitation. It plans to experiment with ways to increase hacker engagement and make the program more attractive.


### [Ten Ways to Secure your Applications](https://yomu.fyi/post/ten-ways-to-secure-your-applications.md)
- Company: [Heroku](https://yomu.fyi/company/heroku.md)
- Author: Joe Kutner
- Published: Feb 21, 2019
- Type: Explainer

The post, adapted from Joe Kutner’s Devoxx 2018 talk, presents ten ways to strengthen web application security, with examples focused on Java but applicable to modern languages. It recommends keeping dependencies current, validating explicit payloads with schemas, checking regular expressions for ReDoS, throttling abusive requests, and keeping credentials outside the codebase. It also advises secure-first coding, certificate validation for outgoing connections, logging security-relevant actions without recording secrets, and monitoring suspicious behavior with tools such as AppSensor. The examples include Maven Versions Plugin, Snyk, Bucket4j, saferegex, environment variables, and EnvKeyStore, with a token-bucket algorithm proposed for request throttling. The conclusion is that security requires anticipating unintended functionality across network, platform, and physical domains, while these practices provide a starting point.


### [Bug Bounty Year in Review 2018](https://yomu.fyi/post/bug-bounty-year-in-review-2018.md)
- Company: [Shopify](https://yomu.fyi/company/shopify.md)
- Author: peter yaworski
- Published: Dec 20, 2018
- Type: Benchmark

Shopify’s 2018 bug bounty review reports its fifth year and most successful program to date, with faster handling and higher payouts. The security team cut average triage time from four days in 2017 to 10 hours in 2018 by assigning one of its 14 Application Security members to HackerOne triage each week. At Montreal’s H1-514 event, over 40 hackers produced more than 50 valid reports, supported by early submissions, disclosed resolved reports, incentive bonuses, expanded scope, and infrastructure shell access. Excluding event statistics, average bounty rose to $1,790, total payouts reached $155,750, 60% of resolved reports received a bounty, and triage, bounty, and resolution times improved, although resolved reports and participating hackers declined and some low-severity reports exceeded the one-month target.


### [Rolling the Heroku Redis Fleet](https://yomu.fyi/post/rolling-the-heroku-redis-fleet.md)
- Company: [Heroku](https://yomu.fyi/company/heroku.md)
- Author: Camille Baldock
- Published: Jun 27, 2018
- Type: Explainer

Heroku proactively rolled its Redis fleet to a version not vulnerable to CVE-2018-11218 during an embargo, aiming to protect customers while limiting disruption and downtime. The operation relied on immutable infrastructure: engineers built, tested, reviewed, and released a new server image, then replaced High Availability standbys before scheduling customer maintenance. During each update, the team verified replication, broke the link so the standby could accept writes, redirected application config vars to the new primary, de-provisioned the old primary, and created a replacement standby. Automation controlled concurrency and limited replacement work to the on-call operator’s business hours, while customers received advance and completion emails. The fleet roll covered all Heroku Redis customers within five weeks of notification and finished one week before the public announcement; the process also applies to Heroku Postgres and Apache Kafka on Heroku.


### [Rails Asset Pipeline Directory Traversal Vulnerability (CVE-2018-3760)](https://yomu.fyi/post/rails-asset-pipeline-directory-traversal-vulnerability-cve-2018-3760.md)
- Company: [Heroku](https://yomu.fyi/company/heroku.md)
- Author: Richard Schneeman
- Published: Jun 19, 2018
- Type: Incident / postmortem

All previously released versions of Sprockets, which powers the Rails asset pipeline, contained a directory traversal vulnerability, CVE-2018-3760. Rails applications were vulnerable when production runtime asset compilation was enabled with config.assets.compile = true; the default production setting was false, so apps using the default were not vulnerable. Sprockets handled requests by searching for rendered assets and compiling matches dynamically, and an attacker could exploit that process with a crafted URL based on a known absolute source-asset path to make it appear inside a permitted path. Patches were prepared for Sprockets versions 2, 3, and 4, with remediation via disabling runtime compilation or upgrading to versions 2.12.5, 3.7.2, or 4.0.0.beta8. Heroku also updated its Ruby Buildpack to fail affected builds, notified customers, and warned that compromised applications may require credential rotation.


### [Ruby CVE-2017-17405: Vulnerability in Ruby’s FTP Implementation](https://yomu.fyi/post/ruby-cve-2017-17405-vulnerability-in-ruby-s-ftp-implementation.md)
- Company: [Heroku](https://yomu.fyi/company/heroku.md)
- Author: Etienne Stalmans
- Published: Apr 6, 2018
- Type: Incident / postmortem

CVE-2017-17405 affected Ruby’s net/ftp implementation, where a filename returned by an FTP server could reach Ruby’s open function and enable command execution. The issue was found while investigating CVE-2017-8817 in libcurl and checking whether Ruby used libcurl or had a separate FTP implementation with comparable wildcard behavior. Reviewing Ruby 2.4.2 source identified the 1,496-line ftp.rb file and the gettextfile method, which called open(localfile, "w") without validating the value. A proof of concept made an FTP client request a file list containing a pipe-prefixed payload; Ruby passed it to the shell, producing remote code execution and creating a file containing id output. Ruby replaced open with File.open, released the fix in 2.4.3, and assigned CVE-2017-17405; affected versions included Ruby 2.2.8 and earlier, 2.3.5 and earlier, 2.4.2 and earlier, and 2.5.0-preview1.


### [A House of Cards: An Exploration of Security When Building Docker Containers](https://yomu.fyi/post/a-house-of-cards-an-exploration-of-security-when-building-docker-conta.md)
- Company: [Heroku](https://yomu.fyi/company/heroku.md)
- Author: Etienne Stalmans
- Published: Mar 8, 2018
- Type: Incident / postmortem

The post examines how a Docker-based, multi-tenant build environment can expose untrusted code when layered isolation is misconfigured. It traces a setup using AWS CodeBuild, Docker-in-Docker, and per-step build containers, then tests directory traversal through configurable Dockerfile paths before focusing on daemon networking. The vulnerability comes from starting dockerd with tcp://0.0.0.0:2375 and placing containers on a shared default network; build code can reach the daemon, issue Docker commands, mount the host filesystem, and retrieve container-managed AWS credentials. The excerpt reports a reverse shell, access to the CodeBuild filesystem, and temporary credentials whose impact depends on IAM permissions, while noting that the build must remain alive. The stated fix is to remove the TCP listener and retain the mapped Unix socket.


### [Using HTTP Headers to Secure Your Site](https://yomu.fyi/post/using-http-headers-to-secure-your-site.md)
- Company: [Heroku](https://yomu.fyi/company/heroku.md)
- Author: Caleb Hearth
- Published: Mar 1, 2018
- Type: Tutorial

A straightforward Static Buildpack app received an F, scoring 20/100 in Mozilla Observatory because several security response headers were missing, despite redirecting visitors to HTTPS with an Automated Certificate Management certificate. The walkthrough examines failures for Content Security Policy, HTTP Strict Transport Security, X-Content-Type-Options, X-Frame-Options and X-XSS-Protection, then configures them through the static.json headers collection. The CSP restricts resource origins, blocks inline scripts by default, and uses a SHA-256 hash to permit the Google Analytics inline script without adding unsafe-inline. HSTS uses max-age=63072000, includeSubDomains and optionally preload, while other headers supply MIME sniffing, iframe and legacy XSS protections. After the changes, the reported checks pass, the configuration reaches an A and is later described as A+; the final recommendation adds Referrer-Policy and omits opt-in HSTS preload.


### [2017 Bug Bounty Year in Review](https://yomu.fyi/post/2017-bug-bounty-year-in-review.md)
- Company: [Shopify](https://yomu.fyi/company/shopify.md)
- Author: peter yaworski
- Published: Feb 22, 2018
- Type: Announcement

Shopify’s 2017 bug bounty review reports higher payouts, four-hour average first responses, four-day triage, and changes intended to improve researcher participation. The program paid $67,550 outside the H1-415 event, with an average bounty of almost $1,100, while 121 reports were resolved and 63.1% of submissions were closed as not applicable. At H1-415, five hackers helped resolve 15 bugs for $42,000, and the program’s largest individual payout, $20,000, addressed unauthorized collaborator access caused by account-conversion logic. Shopify also acknowledges fewer resolved reports and delayed low-severity cases, then announces a $500 minimum payment at triage, clearer scope and payout guidance, a $25,000 typical maximum, and earlier access to beta functionality for eligible whitehat partner accounts.


### [How Shopify Governs Containers at Scale with Grafeas and Kritis](https://yomu.fyi/post/how-shopify-governs-containers-at-scale-with-grafeas-and-kritis.md)
- Company: [Shopify](https://yomu.fyi/company/shopify.md)
- Author: Jonathan jonathan.pulsifer@shopify.com
- Published: Oct 12, 2017
- Type: Explainer

Shopify describes using Grafeas and Kritis to govern container software across a platform handling more than 6,000 container builds per day and 330,000 images in its primary registry. Grafeas serves as a central store for metadata about container origins, builds, base images, layers, registry pulls, installed packages, vulnerabilities, and deployment status, supporting auditing and lifecycle strategies. During CI, audits produce attestations, which Shopify signs with PGP; Kritis uses named attestation authorities and Kubernetes policies to require specific attestations before deployment. Policies can require containers to be built by Shopify, sourced from a trusted repository, free of newly introduced vulnerabilities, tested, non-root, and deployed with the appropriate security context. Shopify also generates attestations from kubeaudit results for workload manifests, helping catch runtime-security regressions before deployment.


### [Preparing Our Response to the OpenSSL Security Flaw](https://yomu.fyi/post/preparing-our-response-to-the-openssl-security-flaw.md)
- Company: [Heroku](https://yomu.fyi/company/heroku.md)
- Author: Kevin Thompson
- Published: Jul 30, 2015
- Type: Incident / postmortem

Heroku prepared for an announced high-severity OpenSSL vulnerability whose details were embargoed until patch release. The team began by mapping exposure and system criticality, considering SSL clients, possible man-in-the-middle attacks, encrypted database connections, and worst-case remote code execution, then created stack-image update actions and priorities. Engineers were assigned responsibilities under the existing incident-response process, with communication rules, escalation criteria, paging, and availability planned in advance. When the OpenSSL update and vulnerability details arrived on July 9 at about 8am Central, triage showed it was neither an RCE nor server-side issue, and Ubuntu reported that neither LTS version was affected; because Heroku production used LTS, no remediation or all-hands response was needed. The preparation still exercised exposure review and response coordination for future incidents.


[Newer posts](https://yomu.fyi/topic/security/page/8.md) · [Older posts](https://yomu.fyi/topic/security/page/10.md)