#ruby
Rulesets (16)

Scan code for potential security issues that require additional review. Recommended for teams looking to set up guardrails or to flag troublesome spots for further review.

Scan code for potential security issues that require additional review. Recommended for teams looking to set up guardrails or to flag troublesome spots for further review.

Secure defaults for XSS prevention for Ruby on Rails

Secure defaults for XSS prevention

Ensure your code communicates over encrypted channels instead of plaintext.

Default ruleset for Ruby, curated by r2c.

Rules for detecting secrets checked into version control

Use recommended rulesets specific to your project. Auto config is not a ruleset but a mode that scans for languages and frameworks and then uses the Semgrep Registry to select recommended rules. Semgrep will send a list of languages, frameworks, and your project URL to the Registry when using auto mode (but code is never uploaded).

Brakeman ruleset curated by r2c.

Omni pack for insecure transport rules

Ensure your code communicates over encrypted channels instead of plaintext.

SQL injection guardrails. Checks for non-constant SQL queries and other SQLi.

Secure defaults for Command injection prevention

Secure defaults for XSS prevention for Ruby on Rails
Rules (122)

Checks for requests to http (unencrypted) sites using some of ruby's most popular REST/HTTP libraries, including httparty and restclient.

Checks for outgoing connections to ftp servers with the 'net/ftp' package. FTP does not encrypt traffic, possibly leading to PII being sent plaintext over the network. Instead, connect via the SFTP protocol.

Checks for requests sent to http:// URLs. This is dangerous as the server is attempting to connect to a website that does not encrypt traffic with TLS. Instead, only send requests to https:// URLs.

Checks for creation of telnet servers or attempts to connect through telnet. This is insecure as the telnet protocol supports no encryption, and data passes through unencrypted.

Checks for requests to http and ftp (unencrypted) sites using OpenURI.

Password is exposed through JWT token payload. This is not encrypted and the password could be compromised. Do not store passwords in JWT tokens.

Hardcoded JWT secret or private key is used. This is a Insufficiently Protected Credentials weakness: https://cwe.mitre.org/data/definitions/522.html Consider using an appropriate security mechanism to protect the credentials (e.g. keeping secrets in environment variables)

Detected use of the 'none' algorithm in a JWT token. The 'none' algorithm assumes the integrity of the token has already been verified. This would allow a malicious actor to forge a JWT token that will automatically be verified. Do not explicitly use the 'none' algorithm. Instead, use an algorithm such as 'HS256'.

Detected the decoding of a JWT token without a verify step. JWT tokens must be verified before use, otherwise the token's integrity is unknown. This means a malicious actor could forge a JWT token with any claims.

The object is passed strictly to jsonwebtoken.sign(...) Make sure that sensitive information is not exposed through JWT token payload.

Checks if code allows cookies to be deserialized using Marshal. If the attacker can craft a valid cookie, this could lead to remote code execution. The hybrid check is just to warn users to migrate to :json for best practice.

Checks for strong parameter bypass through usage of create_with. Create_with bypasses strong parameter protection, which could allow attackers to set arbitrary attributes on models. To fix this vulnerability, either remove all create_with calls or use the permit function to specify tags that are allowed to be set.

Detected a possible ZeroDivisionError.

When a 'Hash' with user-supplied input is encoded in JSON, Rails doesn't provide adequate escaping. If the JSON string is supplied into HTML, the page will be vulnerable to XXS attacks. The affected Rails versions are 3.0.x, 3.1.x, 3.2.x, 4.1.x, 4.2.x. To fix, either upgrade or add an initializer.

Checks for models that do not use attr_accessible. This means there is no limiting of which variables can be manipulated through mass assignment. For newer Rails applications, parameters should be allowlisted using strong parameters. For older Rails versions, they should be allowlisted using strong_attributes.

'html_safe()' does not make the supplied string safe. 'html_safe()' bypasses HTML escaping. If external data can reach here, this exposes your application to cross-site scripting (XSS) attacks. Ensure no external data reaches here.

'render text: ...' actually sets the content-type to 'text/html'. If external data can reach here, this exposes your application to cross-site scripting (XSS) attacks. Instead, use 'render plain: ...' to render non-HTML text.

Detected non-static command inside $EXEC. Audit the input to '$EXEC'. If unverified user data can reach this call site, this is a code injection vulnerability. A malicious actor can inject a malicious script to execute arbitrary code.

Detected non-static command inside 'open'. Audit the input to 'open'. If unverified user data can reach this call site, this is a code injection vulnerability. A malicious actor can inject a malicious script to execute arbitrary code.

Detected non-static command inside $PIPE. Audit the input to '$PIPE'. If unverified user data can reach this call site, this is a code injection vulnerability. A malicious actor can inject a malicious script to execute arbitrary code.

'syscall' is essentially unsafe and unportable. The DL (https://apidock.com/ruby/Fiddle) library is preferred for safer and a bit more portable programming.

Detected non-static command inside `...`. If unverified user data can reach this call site, this is a code injection vulnerability. A malicious actor can inject a malicious script to execute arbitrary code.

Checks for unsafe deserialization. Objects in Ruby can be serialized into strings, then later loaded from strings. However, uses of load and object_load can cause remote code execution. Loading user input with MARSHAL or CSV can potentially be dangerous. Use JSON in a secure fashion instead.

Special requests can determine whether a file exists on a filesystem that's outside the Rails app's root directory. To fix this, set config.serve_static_assets = false.

Checks for use of action in Ruby routes. This can cause Rails to render an arbitrary view if an attacker creates an URL accurately. Affects 3.0 applications. Can avoid the vulnerability by providing additional constraints.

Checks for configuration setting of force_ssl to false. Force_ssl forces usage of HTTPS, which could lead to network interception of unencrypted application traffic. To fix, set config.force_ssl = true.

Detected hardcoded password used in basic authentication in a controller class. Including this password in version control could expose this credential. Consider refactoring to use environment variables or configuration files.

The JDOM backend for XmlMini has a vulnerability that lets an attacker perform a denial of service attack or gain access to files on the application server. This affects versions 3.0, but is fixed in versions 3.1.12 and 3.2.13. To fix, either upgrade or use XmlMini.backend="REXML".

Checks if HTML escaping is globally disabled for JSON output. This could lead to XSS.

Mass assignment protection disabled for '$MODEL'. This could permit assignment to sensitive model fields without intention. Instead, use 'attr_accessible' for the model or disable mass assigment using 'config.active_record.whitelist_attributes = true'. ':without_protection => true' must be removed for this to take effect.

Detected controller which does not enable cross-site request forgery protections using 'protect_from_forgery'. Add 'protect_from_forgery :with => :exception' to your controller class.

Checks for models that use attr_protected, as use of allowlist instead of denylist is better practice. Attr_protected was also found to be vulnerable to bypass. The fixed versions of Rails are: 3.2.12, 3.1.11, 2.3.17. To prevent bypass, use attr_accessible instead.

Checks for nested attributes vulnerability (CVE-2015-7577). Setting allow_destroy: false in accepts_nested_attributes_for can lead to attackers setting attributes to invalid values and clearing all attributes. This affects versions 3.1.0 and newer, with fixed versions 5.0.0.beta1.1, 4.2.5.1, 4.1.14.1, 3.2.22.1. To fix, upgrade to a newer version or use the initializer specified in the google groups.

Checks for models that enable nested attributes. A vulnerability in nested_attributes_for results in an attacker begin able to change parameters apart from the ones intended by the developer. Affected Rails versions: 3.0.0, 2.3.9. Fix: don't use accepts_nested_attributes_for or upgrade Rails version.

Use of eval with user-controllable input detected. This can lead to attackers running arbitrary code. Ensure external data does not reach here, otherwise this is a security vulnerability. Consider other ways to do this without eval.

Detected SSL that will accept an unverified connection. This makes the connections susceptible to man-in-the-middle attacks. Use 'OpenSSL::SSL::VERIFY_PEER' instead.

Checks for unsafe use of method http_basic_authenticate_with, which is vulnerable to timing attacks as it does not use constant-time checking when comparing passwords. Affected Rails versions include: 5.0.0.beta1.1, 4.2.5.1, 4.1.14.1, 3.2.22.1. Avoid this function if possible.

Checks for calls to without_protection during mass assignment (which allows record creation from hash values). This can lead to users bypassing permissions protections. For Rails 4 and higher, mass protection is on by default. Fix: Don't use :without_protection => true. Instead, configure attr_accessible to control attribute access.

Should not use SHA1 to generate hashes. There is a proven SHA1 hash collision by Google, which could lead to vulnerabilities. Use SHA256, SHA3 or other hashing functions instead.

Detected enabled YAML parsing. This is vulnerable to remote code execution in Rails 2.x versions up to 2.3.14. To fix, delete this line.

'content_tag()' bypasses HTML escaping for some portion of the content. If external data can reach here, this exposes your application to cross-site scripting (XSS) attacks. Ensure no external data reaches here. If you must do this, create your HTML manually and use 'html_safe'. Ensure no external data enters the HTML-safe string!

'raw()' bypasses HTML escaping. If external data can reach here, this exposes your application to cross-site scripting (XSS) attacks. If you must do this, construct individual strings and mark them as safe for HTML rendering with `html_safe()`.

'render inline: ...' renders an entire ERB template inline and is dangerous. If external data can reach here, this exposes your application to server-side template injection (SSTI) or cross-site scripting (XSS) attacks. Instead, consider using a partial or another safe rendering method.

Detected manual creation of an ERB template. Manual creation of templates may expose your application to server-side template injection (SSTI) or cross-site scripting (XSS) attacks if user input is used to create the template. Instead, create a '.erb' template file and use 'render'.

Detected string concatenation with a non-literal variable in a pg Ruby SQL statement. This could lead to SQL injection if the variable is user-controlled and not properly sanitized. In order to prevent SQL injection, use parameterized queries or prepared statements instead. You can use parameterized queries like so: `conn.exec_params('SELECT $1 AS a, $2 AS b, $3 AS c', [1, 2, nil])` And you can use prepared statements with `exec_prepared`.

Using user input when accessing files is potentially dangerous. A malicious actor could use this to modify or access files they have no right to.

Detected user input flowing into a manually constructed HTML string. You may be accidentally bypassing secure methods of rendering HTML by manually constructing HTML and this could create a cross-site scripting vulnerability, which could let attackers steal sensitive user data. Use the `render template` and make template files which will safely render HTML instead, or inspect that the HTML is absolutely rendered safely with a function like `sanitize`.

Detected user input used to manually construct a SQL string. This is usually bad practice because manual construction could accidentally result in a SQL injection. An attacker could use a SQL injection to steal or modify contents of the database. Instead, use a parameterized query which is available by default in most database engines. Alternatively, consider using an object-relational mapper (ORM) such as ActiveRecord which will protect your queries.

This code contains bidirectional (bidi) characters. While this is useful for support of right-to-left languages such as Arabic or Hebrew, it can also be used to trick language parsers into executing code in a manner that is different from how it is displayed in code editing and review tools. If this is not what you were expecting, please review this code in an editor that can reveal hidden Unicode characters.

Detected SQL statement that is tainted by `event` object. This could lead to SQL injection if the variable is user-controlled and not properly sanitized. In order to prevent SQL injection, use parameterized queries or prepared statements instead. You can use parameterized statements like so: `conn.exec_params('SELECT $1 AS a, $2 AS b, $3 AS c', [1, 2, nil])`

Detected SQL statement that is tainted by `event` object. This could lead to SQL injection if the variable is user-controlled and not properly sanitized. In order to prevent SQL injection, use parameterized queries or prepared statements instead. You can use parameterized statements like so: `DB['select * from items where name = ?', name]`

Detected user input used to manually construct a SQL string. This is usually bad practice because manual construction could accidentally result in a SQL injection. An attacker could use a SQL injection to steal or modify contents of the database. Instead, use a parameterized query which is available by default in most database engines. Alternatively, consider using an object-relational mapper (ORM) such as Sequelize which will protect your queries.

Calling `permit` on security-critical properties like `$ATTRIBUTE` may leave your application vulnerable to mass assignment.

Calling `permit` on security-critical properties like `$ATTRIBUTE` may leave your application vulnerable to mass assignment.

Found a Brakeman-style secret - a variable with the name password/secret/api_key/rest_auth_site_key and a non-empty string literal value.

Allowing user input to `send_file` allows a malicious user to potentially read arbitrary files from the server. Avoid accepting user input in `send_file` or normalize with `File.basename(...)`

Unsafe deserialization from YAML. Objects in Ruby can be serialized into strings, then later loaded from strings. However, uses of load and object_load can cause remote code execution. Loading user input with YAML can potentially be dangerous. Use JSON in a secure fashion instead. However, loading YAML from a static file is not dangerous and should not be flagged.

Found a Rails `cookie_store` session configuration setting the `$KEY` attribute to `false`. If using a cookie-based session store, the HttpOnly and Secure flags should be set.

Found potentially unsafe handling of redirect behavior $X. Do not pass `params` to `redirect_to` without the `:only_path => true` hash value.

Found an unscoped `find(...)` with user-controllable input. If the ActiveRecord model being searched against is sensitive, this may lead to Insecure Direct Object Reference (IDOR) behavior and allow users to read arbitrary records. Scope the find to the current user, e.g. `current_user.accounts.find(params[:id])`.

Default routes are enabled in this routes file. This means any public method on a controller can be called as an action. It is very easy to accidentally expose a method you didn't mean to. Instead, remove this line and explicitly include all routes you intend external users to follow.

This code includes user input in `link_to`. In Rails 2.x, the body of `link_to` is not escaped. This means that user input which reaches the body will be executed when the HTML is rendered. Even in other versions, values starting with `javascript:` or `data:` are not escaped. It is better to create and use a safer function which checks the body argument.

When a redirect uses user input, a malicious user can spoof a website under a trusted URL or access restricted parts of a site. When using user-supplied values, sanitize the value before using it for the redirect.

Avoid rendering user input. It may be possible for a malicious user to input a path that lets them access a template they shouldn't. To prevent this, check dynamic template paths against a predefined allowlist to make sure it's an allowed template.

User data flows into the host portion of this manually-constructed URL. This could allow an attacker to send data to their own server, potentially exposing sensitive data such as cookies or authorization information sent with this request. They could also probe internal servers or other resources that the server runnig this code can access. (This is called server-side request forgery, or SSRF.) Do not allow arbitrary hosts. Use the `ssrf_filter` gem and guard the url construction with `SsrfFilter(...)`, or create an allowlist for approved hosts.

This call turns off CSRF protection allowing CSRF attacks against the application

Deserialization of a string tainted by `event` object found. Objects in Ruby can be serialized into strings, then later loaded from strings. However, uses of `load` can cause remote code execution. Loading user input with MARSHAL, YAML or CSV can potentially be dangerous. If you need to deserialize untrusted data, you should use JSON as it is only capable of returning 'primitive' types such as strings, arrays, hashes, numbers and nil.

Detected use of mail_to helper used with the `:encode => :javascript option`. The attacker could specify a malicious name or email value that could lead to a XSS attack. Instead, use `:encode => :hex` or patch to Rails 3.0.4 or 2.3.11.

All versions below 1.2.1 of the 'actionpack_page-caching' gem are vulnerable to arbitrary file write and remote code execution (CVE-2020-8159) when using caching methods. Update to version 1.2.1 or greater or remove calls to 'caches_page'.

This application is explicitly enabling external entities enabling an attacker to inject malicious XML to exploit an XML External Entities (XXE) vulnerability. This could let the attacker cause a denial-of-service by forcing the parser to parse large files, or at worst, let the attacker download sensitive files or user data. Use the built-in Rails XML parser, REXML, instead.

Found an improperly constructed control flow block with `request.get?`. Rails will route HEAD requests as GET requests but they will fail the `request.get?` check, potentially causing unexpected behavior unless an `elif` condition is used.

This application is using LibXML as the XML backend. LibXML can be vulnerable to XML External Entities (XXE) vulnerabilities. Use the built-in Rails XML parser, REXML, instead.

Checks for unsafe deserialization. Objects in Ruby can be serialized into strings, then later loaded from strings. However, uses of load and object_load can cause remote code execution. Loading user input with MARSHAL or CSV can potentially be dangerous. Use JSON in a secure fashion instead.
Insufficient permissions to view rule definition Upgrade to Semgrep Team tier to see this Pro rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team tier to see this Pro rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team tier to see this Pro rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team tier to see this Pro rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team tier to see this Pro rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team tier to see this Pro rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team tier to see this Pro rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team tier to see this Pro rule. Visit https://semgrep.dev/pricing to learn how to upgrade.

Checks for dangerous permitted attributes that can lead to mass assignment vulnerabilities. Query parameters allowed using permit and attr_accessible are checked for allowance of dangerous attributes admin, banned, role, and account_id. Also checks for usages of params.permit!, which allows everything. Fix: don't allow admin, banned, role, and account_id using permit or attr_accessible.

Checks for unsafe use of Object#send, try, __send__, and public_send. These only account for unsafe use of a method, not target. This can lead to arbitrary calling of exit, along with arbitrary code execution. Please be sure to sanitize input in order to avoid this.

Should not use md5 to generate hashes. md5 is proven to be vulnerable through the use of brute-force attacks. Could also result in collisions, leading to potential collision attacks. Use SHA256 or other hashing functions instead.

This gets data from session using user inputs. A malicious user may be able to retrieve information from your session that you didn't intend them to. Do not use user input as a session key.

Using user input when accessing files is potentially dangerous. A malicious actor could use this to modify or access files they have no right to.

Using user input when accessing files is potentially dangerous. A malicious actor could use this to modify or access files they have no right to.

Using user input when accessing files is potentially dangerous. A malicious actor could use this to modify or access files they have no right to.

It looks like MD5 is used as a password hash. MD5 is not considered a secure password hash because it can be cracked by an attacker in a short amount of time. Instead, use a suitable password hashing function such as bcrypt. You can use the `bcrypt` gem.

Found that the setting for providing detailed exception reports in Rails is set to true. This can lead to information exposure, where sensitive system or internal information is displayed to the end user. Instead, turn this setting off.

Discovered an application that uses MySQL and find_by_* dynamic finders on potentially sensitive fields. There is a vulnerability in MySQL integer conversion, which could case "0" to match any string, and could therefore lead to sensitive data being exposed. Instead, upgrade to Rails version 4.

Detected usage of `Mime.const_set`. This could lead to a Denial of Service attack, as an attacker could send lots of different mime types to the server, causing the cache to grow large and use all available RAM. Make sure you are using 5.0.0.beta1.1, 4.2.5.1, 4.1.14.1, 3.2.22.1 or higher. If this is not possible, use the workaround with "Mime.const_set :LOOKUP, Hash.new { |h,k| Mime::Type.new(k) unless k.blank? }"

Detected user input flowing into number_to_currency helper. One of the parameters to the helper (unit) is not escaped correctly and could lead to XSS, which in turn could lead to sensitive data being exfiltrated. Instead, sanitize data before passing it into `number_to_currency` with the html_escape (h) function or upgrade to Rails 4.0.2 or 3.2.16.

Detected usage of `quote_table_name`, which has a vulnerability allowing malicious users to inject arbitrary SQL into a query. This is fixed in Rails versions 3.0.10, 2.3.13, and 3.1.0.rc5 and above. If updating your Rails version is not possible, sanitize input thoroughly before passing it to a `quote_table_name` call.

Detected SQL statement that is tainted by `event` object. This could lead to SQL injection if the variable is user-controlled and not properly sanitized. In order to prevent SQL injection, use parameterized queries or prepared statements instead. You can use parameterized statements like so: `Example.find_by_sql ["SELECT title FROM posts WHERE author = ? AND created > ?", author_id, start_date]`

Detected SQL statement that is tainted by `event` object. This could lead to SQL injection if the variable is user-controlled and not properly sanitized. In order to prevent SQL injection, use parameterized queries or prepared statements instead. You can use sanitize statements like so: `escaped = client.escape(user_input)`

Found a call to `render $T` after calling `$T.save`. Do not call `render` after calling `save` on an ActiveRecord object. Reloading the page will cause the state-changing operation to be repeated which may cause undesirable side effects. Use `redirect_to` instead.

Found request parameters in a call to `render`. This can allow end users to request arbitrary local files which may result in leaking sensitive information persisted on disk. Where possible, avoid letting users specify template paths for `render`. If you must allow user input, use an allow-list of known templates or normalize the user-supplied value with `File.basename(...)`.

Found a string literal assignment to a Rails session secret `$KEY`. Do not commit secret values to source control! Any user in possession of this value may falsify arbitrary session data in your application. Read this value from an environment variable, KMS, or file on disk outside of source control.

Found a potentially user-controllable argument in the construction of a regular expressions. This may result in excessive resource consumption when applied to certain inputs, or when the user is allowed to control the match target. Avoid allowing users to specify regular expressions processed by the server. If you must support user-controllable input in a regular expression, use an allow-list to restrict the expressions users may supply to limit catastrophic backtracking.

Disabled-by-default Rails controller checks make it much easier to introduce access control mistakes. Prefer an allowlist approach with `:only => [...]` rather than `except: => [...]`

Found potential SQL injection due to unsafe SQL query construction via $X. Where possible, prefer parameterized queries.

Found user-controllable input to a reflection method. This may allow a user to alter program behavior and potentially execute arbitrary instructions in the context of the process. Do not provide arbitrary user input to `tap`, `method`, or `to_proc`

Found the use of an hardcoded passphrase for RSA. The passphrase can be easily discovered, and therefore should not be stored in source-code. It is recommended to remove the passphrase from source-code, and use system environment variables or a restricted configuration file.

The RSA key size $SIZE is insufficent by NIST standards. It is recommended to use a key length of 2048 or higher.

Found user-controllable input to Ruby reflection functionality. This allows a remote user to influence runtime behavior, up to and including arbitrary remote code execution. Do not provide user-controllable input to reflection functionality. Do not call symbol conversion on user-controllable input.

$V Found an incorrectly-bounded regex passed to `validates_format_of` or `validate ... format => ...`. Ruby regex behavior is multiline by default and lines should be terminated by `\A` for beginning of line and `\Z` for end of line, respectively.
Insufficient permissions to view rule definition Upgrade to Semgrep Team tier to see this Pro rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team tier to see this Pro rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team tier to see this Pro rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team tier to see this Pro rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team tier to see this Pro rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team tier to see this Pro rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team tier to see this Pro rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team tier to see this Pro rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team tier to see this Pro rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team tier to see this Pro rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team tier to see this Pro rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team tier to see this Pro rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team tier to see this Pro rule. Visit https://semgrep.dev/pricing to learn how to upgrade.
Insufficient permissions to view rule definition Upgrade to Semgrep Team tier to see this Pro rule. Visit https://semgrep.dev/pricing to learn how to upgrade.

The $COLUMN column appears to be a foreign key. Would it benefit from an index? Having an index can improve performance.