CSPViolationReportBody: lineNumber property

The lineNumber read-only property of the CSPViolationReportBody interface indicates the line number in the source file that triggered the Content Security Policy (CSP) violation.

Note that the browser extracts the value from the global object of the file that triggered the violation. If the resource that triggers the CSP violation is not loaded, the value will be null. See CSPViolationReportBody.sourceFile for more information.

This property is most useful alongside CSPViolationReportBody.sourceFile and CSPViolationReportBody.columnNumber, as it provides the location of the line in that file and the column that resulted in a violation.

Value

An integer containing the line number that triggered the violation, or null.

Examples

CSP inline script violation

This example triggers a CSP violation using an inline script, and reports the violation using a ReportingObserver.

HTML

The HTML file below uses the <meta> element to set the Content-Security-Policy default-src to self, which allows scripts and other resources to be loaded from the same origin, but does not allow inline scripts to be executed. The document also includes an inline script, which should therefore trigger a CSP violation.

html
<!doctype html>
<html lang="en">
  <head>
    <meta
      http-equiv="Content-Security-Policy"
      content="default-src 'self'; report-to csp-endpoint" />
    <meta
      http-equiv="Reporting-Endpoints"
      content="csp-endpoint='https://example.com/csp-reports'" />
    <script src="main.js"></script>
    <title>CSP: Violation due to inline script</title>
  </head>
  <body>
    <h1>CSP: Violation due to inline script</h1>
    <script>
      const int = 4;
    </script>
  </body>
</html>

JavaScript (main.js)

The document above also loads the external script main.js, which is shown below. Because this is loaded from the same domain as the HTML, it is not blocked by the CSP.

The script creates a new ReportingObserver to observe content violation reports of type "csp-violation". Each time the callback function is invoked, we get the body of the first entry of the reports array, and use it to log the file, line, and column of the violation to the console.

js
// main.js
const observer = new ReportingObserver(
  (reports, observer) => {
    const cspViolationBody = reports[0].body;
    console.log(`sourceFile: ${cspViolationBody.sourceFile}`);
    console.log(`lineNumber: ${cspViolationBody.lineNumber}`);
    console.log(`columnNumber: ${cspViolationBody.columnNumber}`);
  },
  {
    types: ["csp-violation"],
    buffered: true,
  },
);

observer.observe();

Note that while there might be multiple reports in the returned array, for brevity we only log the values of the first element.

Results

You can try this out using a local server. Copy the above code into test/index.html and test/main.js and run the server in the root directory. Assuming the address of the local server is http://127.0.0.1:9999, you can then load the HTML file from http://127.0.0.1:9999/test/ (or http://127.0.0.1:9999/test/index.html).

With the above setup, the output of the log on Chrome is:

sourceFile: http://127.0.0.1:9999/test/
lineNumber: 15
columnNumber: 0

The result is similar for Firefox:

sourceFile: http://127.0.0.1:9999/test/
lineNumber: 15
columnNumber: 13

Note that the column number is different for the two browsers. Chrome always appears to report 0. The value on Firefox represents the position of the first character after the end of the opening <script> element.

Specifications

Specification
Content Security Policy Level 3
# dom-cspviolationreportbody-linenumber

Browser compatibility

BCD tables only load in the browser

See also