Showing 119 of 119 total issues
ruby-ffi DDL loading issue on Windows OS Open
ffi (1.9.14)
- Read upRead up
- Exclude checks
Advisory: CVE-2018-1000201
Criticality: High
URL: https://github.com/ffi/ffi/releases/tag/1.9.24
Solution: upgrade to >= 1.9.24
Path Traversal in Sprockets Open
sprockets (3.7.0)
- Read upRead up
- Exclude checks
Advisory: CVE-2018-3760
Criticality: High
URL: https://groups.google.com/forum/#!topic/ruby-security-ann/2S9Pwz2i16k
Solution: upgrade to < 3.0.0, >= 2.12.5, < 4.0.0, >= 3.7.2, >= 4.0.0.beta8
Regular Expression Denial of Service in websocket-extensions (RubyGem) Open
websocket-extensions (0.1.2)
- Read upRead up
- Exclude checks
Advisory: CVE-2020-7663
Criticality: High
URL: https://github.com/faye/websocket-extensions-ruby/security/advisories/GHSA-g6wq-qcwm-j5g2
Solution: upgrade to >= 0.1.5
File Content Disclosure in Action View Open
actionview (5.0.0.1)
- Read upRead up
- Exclude checks
Advisory: CVE-2019-5418
Criticality: High
URL: https://groups.google.com/forum/#!topic/rubyonrails-security/pFRKI96Sm8Q
Solution: upgrade to >= 4.2.11.1, ~> 4.2.11, >= 5.0.7.2, ~> 5.0.7, >= 5.1.6.2, ~> 5.1.6, >= 5.2.2.1, ~> 5.2.2, >= 6.0.0.beta3
Denial of service via header parsing in Rack Open
rack (2.0.1)
- Read upRead up
- Exclude checks
Advisory: CVE-2022-44570
URL: https://github.com/rack/rack/releases/tag/v3.0.4.1
Solution: upgrade to >= 2.0.9.2, ~> 2.0.9, >= 2.1.4.2, ~> 2.1.4, >= 2.2.6.2, ~> 2.2.6, >= 3.0.4.1
Possible shell escape sequence injection vulnerability in Rack Open
rack (2.0.1)
- Read upRead up
- Exclude checks
Advisory: CVE-2022-30123
Criticality: Critical
URL: https://groups.google.com/g/ruby-security-ann/c/LWB10kWzag8
Solution: upgrade to >= 2.0.9.1, ~> 2.0.9, >= 2.1.4.1, ~> 2.1.4, >= 2.2.3.1
Denial of Service Vulnerability in Action View Open
actionview (5.0.0.1)
- Read upRead up
- Exclude checks
Advisory: CVE-2019-5419
Criticality: High
URL: https://groups.google.com/forum/#!topic/rubyonrails-security/GN7w9fFAQeI
Solution: upgrade to >= 6.0.0.beta3, >= 5.2.2.1, ~> 5.2.2, >= 5.1.6.2, ~> 5.1.6, >= 5.0.7.2, ~> 5.0.7, >= 4.2.11.1, ~> 4.2.11
Denial of Service Vulnerability in Rack Multipart Parsing Open
rack (2.0.1)
- Read upRead up
- Exclude checks
Advisory: CVE-2022-30122
Criticality: High
URL: https://groups.google.com/g/ruby-security-ann/c/L2Axto442qk
Solution: upgrade to >= 2.0.9.1, ~> 2.0.9, >= 2.1.4.1, ~> 2.1.4, >= 2.2.3.1
XSS vulnerability in rails-html-sanitizer Open
rails-html-sanitizer (1.0.3)
- Read upRead up
- Exclude checks
Advisory: CVE-2018-3741
URL: https://groups.google.com/d/msg/rubyonrails-security/tP7W3kLc5u4/uDy2Br7xBgAJ
Solution: upgrade to >= 1.0.4
Arbitrary path traversal and file access via yard server
Open
yard (0.9.5)
- Read upRead up
- Exclude checks
Advisory: CVE-2019-1020001
Criticality: High
URL: https://github.com/lsegal/yard/security/advisories/GHSA-xfhh-rx56-rxcr
Solution: upgrade to >= 0.9.20
Method symbolize_keys
has a Cognitive Complexity of 7 (exceeds 5 allowed). Consider refactoring. Open
def symbolize_keys(hash)
hash.each_with_object({}) do |(key, value), new_hash|
new_key = key.is_a?(String) ? key.to_sym : key
new_value = value.is_a?(Hash) ? symbolize_keys(value) : value
new_hash[new_key] = new_value
- Read upRead up
Cognitive Complexity
Cognitive Complexity is a measure of how difficult a unit of code is to intuitively understand. Unlike Cyclomatic Complexity, which determines how difficult your code will be to test, Cognitive Complexity tells you how difficult your code will be to read and comprehend.
A method's cognitive complexity is based on a few simple rules:
- Code is not considered more complex when it uses shorthand that the language provides for collapsing multiple statements into one
- Code is considered more complex for each "break in the linear flow of the code"
- Code is considered more complex when "flow breaking structures are nested"
Further reading
'protect_from_forgery' should be called in LooseLeaf::ApplicationController Open
class ApplicationController < ActionController::Base
- Read upRead up
- Exclude checks
Cross-site request forgery is #5 on the OWASP Top Ten. CSRF allows an attacker to perform actions on a website as if they are an authenticated user.
This warning is raised when no call to protect_from_forgery
is found in ApplicationController
. This method prevents CSRF.
For Rails 4 applications, it is recommended that you use protect_from_forgery :with => :exception
. This code is inserted into newly generated applications. The default is to nil
out the session object, which has been a source of many CSRF bypasses due to session memoization.
See the Ruby Security Guide for details.
rails-html-sanitizer 1.0.3 is vulnerable (CVE-2018-3741). Upgrade to 1.0.4 Open
rails-html-sanitizer (1.0.3)
- Read upRead up
- Exclude checks
Loofah 2.0.3 is vulnerable (CVE-2018-8048). Upgrade to 2.1.2 Open
loofah (2.0.3)
- Read upRead up
- Exclude checks
Favor modifier unless
usage when having a single-line body. Another good alternative is the usage of control flow &&
/||
. Open
unless client_version > version
- Read upRead up
- Exclude checks
Checks for if and unless statements that would fit on one line
if written as a modifier if/unless. The maximum line length is
configured in the Metrics/LineLength
cop.
Example:
# bad
if condition
do_stuff(bar)
end
unless qux.empty?
Foo.do_something
end
# good
do_stuff(bar) if condition
Foo.do_something unless qux.empty?
Read-only global 'process' should not be modified. Open
process = require('process')
- Read upRead up
- Exclude checks
Disallow assignment to native objects or read-only global variables (no-global-assign)
JavaScript environments contain a number of built-in global variables, such as window
in browsers and process
in Node.js. In almost all cases, you don't want to assign a value to these global variables as doing so could result in losing access to important functionality. For example, you probably don't want to do this in browser code:
window = {};
While examples such as window
are obvious, there are often hundreds of built-in global objects provided by JavaScript environments. It can be hard to know if you're assigning to a global variable or not.
Rule Details
This rule disallows modifications to read-only global variables.
ESLint has the capability to configure global variables as read-only.
- [Specifying Environments](../user-guide/configuring#specifying-environments)
- [Specifying Globals](../user-guide/configuring#specifying-globals)
Examples of incorrect code for this rule:
/*eslint no-global-assign: "error"*/
Object = null
undefined = 1
/*eslint no-global-assign: "error"*/
/*eslint-env browser*/
window = {}
length = 1
top = 1
/*eslint no-global-assign: "error"*/
/*globals a:false*/
a = 1
Examples of correct code for this rule:
/*eslint no-global-assign: "error"*/
a = 1
var b = 1
b = 2
/*eslint no-global-assign: "error"*/
/*eslint-env browser*/
onload = function() {}
/*eslint no-global-assign: "error"*/
/*globals a:true*/
a = 1
Options
This rule accepts an exceptions
option, which can be used to specify a list of builtins for which reassignments will be allowed:
{
"rules": {
"no-global-assign": ["error", {"exceptions": ["Object"]}]
}
}
When Not To Use It
If you are trying to override one of the native objects.
Related Rules
- [no-extend-native](no-extend-native.md)
- [no-redeclare](no-redeclare.md)
- [no-shadow](no-shadow.md) Source: http://eslint.org/docs/rules/
Block must not be padded by blank lines. Open
export default class TextAreaAdapter {
- Read upRead up
- Exclude checks
require or disallow padding within blocks (padded-blocks)
Some style guides require block statements to start and end with blank lines. The goal is to improve readability by visually separating the block content and the surrounding code.
if (a) {
b();
}
Since it's good to have a consistent code style, you should either always write padded blocks or never do it.
Rule Details
This rule enforces consistent empty line padding within blocks.
Options
This rule has one option, which can be a string option or an object option.
String option:
-
"always"
(default) requires empty lines at the beginning and ending of block statements (exceptswitch
statements and classes) -
"never"
disallows empty lines at the beginning and ending of block statements (exceptswitch
statements and classes)
Object option:
-
"blocks"
require or disallow padding within block statements -
"classes"
require or disallow padding within classes -
"switches"
require or disallow padding withinswitch
statements
always
Examples of incorrect code for this rule with the default "always"
option:
/*eslint padded-blocks: ["error", "always"]*/
if (a) {
b();
}
if (a) { b(); }
if (a)
{
b();
}
if (a) {
b();
}
if (a) {
b();
}
if (a) {
// comment
b();
}
Examples of correct code for this rule with the default "always"
option:
/*eslint padded-blocks: ["error", "always"]*/
if (a) {
b();
}
if (a)
{
b();
}
if (a) {
// comment
b();
}
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint padded-blocks: ["error", "never"]*/
if (a) {
b();
}
if (a)
{
b();
}
if (a) {
b();
}
if (a) {
b();
}
Examples of correct code for this rule with the "never"
option:
/*eslint padded-blocks: ["error", "never"]*/
if (a) {
b();
}
if (a)
{
b();
}
blocks
Examples of incorrect code for this rule with the { "blocks": "always" }
option:
/*eslint padded-blocks: ["error", { "blocks": "always" }]*/
if (a) {
b();
}
if (a) { b(); }
if (a)
{
b();
}
if (a) {
b();
}
if (a) {
b();
}
if (a) {
// comment
b();
}
Examples of correct code for this rule with the { "blocks": "always" }
option:
/*eslint padded-blocks: ["error", { "blocks": "always" }]*/
if (a) {
b();
}
if (a)
{
b();
}
if (a) {
// comment
b();
}
Examples of incorrect code for this rule with the { "blocks": "never" }
option:
/*eslint padded-blocks: ["error", { "blocks": "never" }]*/
if (a) {
b();
}
if (a)
{
b();
}
if (a) {
b();
}
if (a) {
b();
}
Examples of correct code for this rule with the { "blocks": "never" }
option:
/*eslint padded-blocks: ["error", { "blocks": "never" }]*/
if (a) {
b();
}
if (a)
{
b();
}
classes
Examples of incorrect code for this rule with the { "classes": "always" }
option:
/*eslint padded-blocks: ["error", { "classes": "always" }]*/
class A {
constructor(){
}
}
Examples of correct code for this rule with the { "classes": "always" }
option:
/*eslint padded-blocks: ["error", { "classes": "always" }]*/
class A {
constructor(){
}
}
Examples of incorrect code for this rule with the { "classes": "never" }
option:
/*eslint padded-blocks: ["error", { "classes": "never" }]*/
class A {
constructor(){
}
}
Examples of correct code for this rule with the { "classes": "never" }
option:
/*eslint padded-blocks: ["error", { "classes": "never" }]*/
class A {
constructor(){
}
}
switches
Examples of incorrect code for this rule with the { "switches": "always" }
option:
/*eslint padded-blocks: ["error", { "switches": "always" }]*/
switch (a) {
case 0: foo();
}
Examples of correct code for this rule with the { "switches": "always" }
option:
/*eslint padded-blocks: ["error", { "switches": "always" }]*/
switch (a) {
case 0: foo();
}
if (a) {
b();
}
Examples of incorrect code for this rule with the { "switches": "never" }
option:
/*eslint padded-blocks: ["error", { "switches": "never" }]*/
switch (a) {
case 0: foo();
}
Examples of correct code for this rule with the { "switches": "never" }
option:
/*eslint padded-blocks: ["error", { "switches": "never" }]*/
switch (a) {
case 0: foo();
}
if (a) {
b();
}
When Not To Use It
You can turn this rule off if you are not concerned with the consistency of padding within blocks. Source: http://eslint.org/docs/rules/
Block must not be padded by blank lines. Open
export default class Events {
- Read upRead up
- Exclude checks
require or disallow padding within blocks (padded-blocks)
Some style guides require block statements to start and end with blank lines. The goal is to improve readability by visually separating the block content and the surrounding code.
if (a) {
b();
}
Since it's good to have a consistent code style, you should either always write padded blocks or never do it.
Rule Details
This rule enforces consistent empty line padding within blocks.
Options
This rule has one option, which can be a string option or an object option.
String option:
-
"always"
(default) requires empty lines at the beginning and ending of block statements (exceptswitch
statements and classes) -
"never"
disallows empty lines at the beginning and ending of block statements (exceptswitch
statements and classes)
Object option:
-
"blocks"
require or disallow padding within block statements -
"classes"
require or disallow padding within classes -
"switches"
require or disallow padding withinswitch
statements
always
Examples of incorrect code for this rule with the default "always"
option:
/*eslint padded-blocks: ["error", "always"]*/
if (a) {
b();
}
if (a) { b(); }
if (a)
{
b();
}
if (a) {
b();
}
if (a) {
b();
}
if (a) {
// comment
b();
}
Examples of correct code for this rule with the default "always"
option:
/*eslint padded-blocks: ["error", "always"]*/
if (a) {
b();
}
if (a)
{
b();
}
if (a) {
// comment
b();
}
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint padded-blocks: ["error", "never"]*/
if (a) {
b();
}
if (a)
{
b();
}
if (a) {
b();
}
if (a) {
b();
}
Examples of correct code for this rule with the "never"
option:
/*eslint padded-blocks: ["error", "never"]*/
if (a) {
b();
}
if (a)
{
b();
}
blocks
Examples of incorrect code for this rule with the { "blocks": "always" }
option:
/*eslint padded-blocks: ["error", { "blocks": "always" }]*/
if (a) {
b();
}
if (a) { b(); }
if (a)
{
b();
}
if (a) {
b();
}
if (a) {
b();
}
if (a) {
// comment
b();
}
Examples of correct code for this rule with the { "blocks": "always" }
option:
/*eslint padded-blocks: ["error", { "blocks": "always" }]*/
if (a) {
b();
}
if (a)
{
b();
}
if (a) {
// comment
b();
}
Examples of incorrect code for this rule with the { "blocks": "never" }
option:
/*eslint padded-blocks: ["error", { "blocks": "never" }]*/
if (a) {
b();
}
if (a)
{
b();
}
if (a) {
b();
}
if (a) {
b();
}
Examples of correct code for this rule with the { "blocks": "never" }
option:
/*eslint padded-blocks: ["error", { "blocks": "never" }]*/
if (a) {
b();
}
if (a)
{
b();
}
classes
Examples of incorrect code for this rule with the { "classes": "always" }
option:
/*eslint padded-blocks: ["error", { "classes": "always" }]*/
class A {
constructor(){
}
}
Examples of correct code for this rule with the { "classes": "always" }
option:
/*eslint padded-blocks: ["error", { "classes": "always" }]*/
class A {
constructor(){
}
}
Examples of incorrect code for this rule with the { "classes": "never" }
option:
/*eslint padded-blocks: ["error", { "classes": "never" }]*/
class A {
constructor(){
}
}
Examples of correct code for this rule with the { "classes": "never" }
option:
/*eslint padded-blocks: ["error", { "classes": "never" }]*/
class A {
constructor(){
}
}
switches
Examples of incorrect code for this rule with the { "switches": "always" }
option:
/*eslint padded-blocks: ["error", { "switches": "always" }]*/
switch (a) {
case 0: foo();
}
Examples of correct code for this rule with the { "switches": "always" }
option:
/*eslint padded-blocks: ["error", { "switches": "always" }]*/
switch (a) {
case 0: foo();
}
if (a) {
b();
}
Examples of incorrect code for this rule with the { "switches": "never" }
option:
/*eslint padded-blocks: ["error", { "switches": "never" }]*/
switch (a) {
case 0: foo();
}
Examples of correct code for this rule with the { "switches": "never" }
option:
/*eslint padded-blocks: ["error", { "switches": "never" }]*/
switch (a) {
case 0: foo();
}
if (a) {
b();
}
When Not To Use It
You can turn this rule off if you are not concerned with the consistency of padding within blocks. Source: http://eslint.org/docs/rules/
Avoid when
branches without a body. Open
when 'minor'
- Read upRead up
- Exclude checks
This cop checks for the presence of when
branches without a body.
Example:
# bad
case foo
when bar then 1
when baz then # nothing
end
Example:
# good
case foo
when bar then 1
when baz then 2
end
Use %i
or %I
for an array of symbols. Open
task default: [:spec, :lint]
- Read upRead up
- Exclude checks
This cop can check for array literals made up of symbols that are not using the %i() syntax.
Alternatively, it checks for symbol arrays using the %i() syntax on projects which do not want to use that syntax.
Configuration option: MinSize
If set, arrays with fewer elements than this value will not trigger the
cop. For example, a MinSize of
3` will not enforce a style on an array
of 2 or fewer elements.
Example: EnforcedStyle: percent (default)
# good
%i[foo bar baz]
# bad
[:foo, :bar, :baz]
Example: EnforcedStyle: brackets
# good
[:foo, :bar, :baz]
# bad
%i[foo bar baz]