DEV Community: 0xdbe

GitHub: signing commit in a workflow

0xdbe — Thu, 04 Apr 2024 13:30:43 +0000

Committing in your workflow can normally be done using git commands or other actions that perform commits for you.
However, if your repository requires commit signing, it is difficult to manage securely a GPG keys and set up GitHub Runner to sign your commit.
Fortunately, this can be done through the GitHub GraphQL API.

GraphQL Mutation

Github provides a GraphQL Mutation createcommitonbranch which creates a commit.
Commits made using this mutation are automatically signed by GitHub and will be marked as verified in the user interface.

For better reusability, we can define a GraphQL mutation in a file .github/api/createCommitOnBranch.gql:

mutation (
    $githubRepository: String!,
    $branchName: String!,
    $expectedHeadOid: GitObjectID!
    $commitMessage: String!
    $files: [FileAddition!]!
) {
  createCommitOnBranch(
    input: {
    branch:
    {
        repositoryNameWithOwner: $githubRepository,
        branchName: $branchName
    },
    message: {headline: $commitMessage},
    fileChanges: {
        additions: $files
    }
    expectedHeadOid: $expectedHeadOid
    }
  ){
    commit {
    url
    }
  }
}

The following input fields must be set when you call this mutation:

githubRepository
branchName
expectedHeadOid
commitMessage
files

Usage with gh CLI

The mutation can now be called using gh CLI:

gh api graphql \
  -F $githubRepository="owner/repo" \
  -F branchName="main" \
  -F expectedHeadOid=$(git rev-parse HEAD) \
  -F commitMessage="chore: commit file" \
  -F files[][path]="README.md" -F files[][contents]=$(base64 -w0 README.md) \
  -F files[][path]="HELLO.md" -F files[][contents]=$(base64 -w0 HELLO.md) \
  -F 'query=@.github/api/createCommitOnBranch.gql'

Warning: files is an array of FileAddition, but fortunately, the gh CLI allows defining nested objects in fields.

Usage in a GitHub Workflow

In order to sign a new commit in your workflow, you can add a step to call the mutation using the gh CLI:

permissions:
  checks: write
  statuses: write
  contents: write

jobs:

  committing:
    runs-on: ubuntu-latest
    steps:

    - name: checkout
      uses: actions/checkout@v4

    - name: edit file
      run: |
        echo "hello" >> README.md

    - name: commit
      run: |
        gh api graphql \
          -F $githubRepository=$GITHUB_REPOSITORY \
          -F branchName=$BRANCH \
          -F expectedHeadOid=$(git rev-parse HEAD) \
          -F commitMessage="chore: commit file" \
          -F files[][path]="README.md" -F files[][contents]=$(base64 -w0 README.md) \
          -F files[][path]="HELLO.md" -F files[][contents]=$(base64 -w0 HELLO.md) \
          -F 'query=@.github/api/createCommitOnBranch.gql'
      env:
        GH_TOKEN: ${{ github.token }}
        BRANCH: "main"

This commit will be signed by github-actions[bot].

Next.js: consequence of Next/Image on your CSP

0xdbe — Thu, 04 Apr 2024 13:29:11 +0000

The Next/Image component is a crucial part of the Next.js framework, offering image optimization functionalities.
However, utilizing this component can have significant implications for Content Security Policy (CSP).

This article is documented as an ADR (Architectural Decision Record) because, in my perspective, this represents a crucial security decision.
This includes the context of how the decision was made and the consequences of adopting it
Feel free to share this ADR with your team members if you find it beneficial.

Issue

To understand the implications of Next/Image, let's examine the following example extracted from the default Next.js template:

<Image
  className="relative dark:drop-shadow-[0_0_0.3rem_#ffffff70] dark:invert"
  src="/next.svg"
  alt="Next.js Logo"
/>

This component generates the following HTML code:

<img
  alt="Next.js Logo"
  style="color:transparent"
  src="/next.svg"
>

As observed, the outcome contains an unsafe inline style used to conceal the alt text.

There are another properties translated into inline style by Next/Image.
For example, fill property is translated by:

<img
  style="position:absolute;height:100%;width:100%;left:0;top:0;right:0;bottom:0;object-fit:contain;color:transparent"
>

Considered Options

Unsafe Inline

The simplest approach is to allow the unsafe-inline keyword for style-src directive.
However, this leaves you vulnerable to CSS injection attacks.

Unsafe Hashes

Since styles for images are predetermined, we can pre-compute hashes for styles:

echo -n "color:transparent" | openssl dgst -sha256 -binary | openssl base64 -A

Subsequently, you can append the following content to your CSP:

style-src 'self' 'sha256-zlqnbDt84zf1iSefLU/ImC54isoprH/MRiVZGskwexk=' 'unsafe-hashes'

Unfortunately, the unsafe-hashes keyword is necessary to permit hashes for the style attribute.

Remove Style

Even without utilizing any properties that generate inline style, there's only one persistent style attribute that you can't eliminate: color:transparent.

To remove the style attribute, it is possible to create a new component called ImageNoStyle, which omits the style attribute:

// ImageNoStyle.tsx
import NextImage, { getImageProps } from 'next/image';
import { ComponentProps } from 'react';

export default function ImageNoStyle(props: ComponentProps<typeof NextImage>) {
  const { props: nextProps } = getImageProps({
    ...props,
  });

  const { style: _omit, ...delegated } = nextProps;

  return <img {...delegated} />;
}

This component uses getImageProps(), available from Next.js 14.1, to generate image properties and omit the style attribute.
Then, ImageNoStyle can be used like this with the same properties as NextImage:

<ImageNoStyle
  className="relative dark:drop-shadow-[0_0_0.3rem_#ffffff70] dark:invert"
  src="/next.svg"
  alt="Next.js Logo"
  width={180}
  height={37}
  priority
/>

However, it's worth noting that this workaround removes inline style for images.
Consequently, this workaround can modify rendering of an existing website.

HTML Tag

The basic HTML <img> tag can be used to embed an image in react component.

Decision

Pending a resolution for issues 61388 and 45184, it's advisable to refrain from using Next/Image.
Employing the <img> HTML tag helps maintain a strict CSP (Content Security Policy).

This decision is relevant to a new application.
For existing applications, the choice may differ, particularly if image optimization is already in use.

Consequence

Opting for the basic <img> HTML tag means foregoing the image optimization features provided by Next.js, as outlined in the image optimization documentation.

Next.js: Crafting a Strict CSP

0xdbe — Thu, 07 Mar 2024 15:56:21 +0000

Next.js lacks many built-in security measures. In fact, it doesn't offer predefined configurations for your Content Security Policy (CSP). Consequently, setting up CSP becomes your responsibility.
Let's explore how we can implement a CSP.

Requirements

To ensure a Content Security Policy that aligns with the current standards, we need to meet the following requirements:

must include a nonce because Next.js often utilizes inline scripts, such as those for AppRouter.
must be delivered through an HTTP Header. Avoid embedding a CSP in a meta tag with http-equiv as it lacks support for crucial features, such as violation reports and frame-ancestors directive.

Middleware

In Next.js, middleware allows you to execute a function before a request is completed. In our case, a middleware will be used to generate a random nonce and then create HTTP headers before the page renders.

Here is the middleware function, which can be adjusted if a middleware chain is used:

// file: middleware.ts
export function middleware(request: NextRequest) {

  // step 1
  const response = initResponse()

  // step 2
  const reportUri = getReportUri()
  response.headers.set(
    'Report-To', getReportToHeaderValue(reportUri)
  )

  // step 3
  const nonce = getNonce()

  // step 4
  response.headers.set(
    'Content-Security-Policy',
    getContentSecurityPolicyHeaderValue(nonce, reportUri)
  )

  return response
}

Helper functions

Step 1: Initialize Response

The first step involves initializing the response using the following function:

function initResponse(): NextResponse {
  return NextResponse.next()
}

Using NextResponse.next() is suitable, in this case, to create an empty response. Although if you're using a chain middleware where the response is already initialized, you might skip this step.

Step 2: Define CSP Violation Reporting

The second step is defining where CSP violation reports will be sent.

Here's the function:

function getReportToHeaderValue(reportUri: string): string {
  const reportTo = {
    group: 'csp',
    max_age: 10886400, //1 day
    endpoints: [{ url: reportUri }],
  }
  return JSON.stringify(reportTo)
}

Certain providers like Sentry or Datadog offer the capability to collect information on CSP (Content-Security-Policy) violations. Remember, if you're testing violation reports, they won't be sent if you're using localhost hostname or an insecure protocol like http.

Step 3: Generate Nonce

The third step involves generating a random nonce using randomUUID():

function getNonce(): string {
  return Buffer.from(crypto.randomUUID()).toString('base64')
}

Step 4: Generate CSP Content

The final step is to generate the content of the CSP, which is perhaps the most intricate task.

Here's a function to define the CSP:

function getContentSecurityPolicyHeaderValue(
    nonce: string,
    reportUri: string,
  ): string {

    // Default CSP for Next.js
    const contentSecurityPolicyDirective = {
      'base-uri': [`'self'`],
      'default-src': [`'none'`],
      'frame-ancestors': [`'none'`],
      'font-src': [`'self'`],
      'form-action': [`'self'`],
      'frame-src': [`'self'`],
      'connect-src': [`'self'`],
      'img-src': [`'self'`],
      'manifest-src': [`'self'`],
      'object-src': [`'none'`],
      'report-uri': [reportUri], // for old browsers like Firefox
      'report-to': ['csp'], // for modern browsers like Chrome
      'script-src': [
        `'nonce-${nonce}'`,
        `'strict-dynamic'`, // force hashes and nonces over domain host lists
      ],
      'style-src': [`'self'`],
    }

    if (process.env.NODE_ENV === 'development') {
      // Webpack use eval() in development mode for automatic JS reloading
      contentSecurityPolicyDirective['script-src'].push(`'unsafe-eval'`)
    }

    if (process.env.NEXT_PUBLIC_VERCEL_ENV === 'preview') {
      contentSecurityPolicyDirective['connect-src'].push('https://vercel.live')
      contentSecurityPolicyDirective['connect-src'].push('wss://*.pusher.com')
      contentSecurityPolicyDirective['img-src'].push('https://vercel.com')
      contentSecurityPolicyDirective['font-src'].push('https://vercel.live')
      contentSecurityPolicyDirective['frame-src'].push('https://vercel.live')
      contentSecurityPolicyDirective['style-src'].push('https://vercel.live')
    }

    return Object.entries(contentSecurityPolicyDirective)
      .map(([key, value]) => `${key} ${value.join(' ')}`)
      .join('; ')

}

If you need to complete the default CSP, use the push method to add additional sources.

Page Render

Once we have middleware that creates a CSP with a nonce, we need to include this nonce on pages. Every time a page is viewed, a fresh nonce should be generated. This means you must use dynamic rendering to add nonces:

// file: app/layout.tsx
export const dynamic = 'force-dynamic'

With this option, Next.js will be able to insert a random number on the rendered page.

To achieve this, Next.js utilizes getScriptNonceFromHeader to extract the nonce from the CSP HTTP header.
Then, AppRender includes the nonce in all script elements.

Warning: Keep in mind that dynamic rendering can increase hosting costs. For example, on Vercel, page rendering is done as a serverless function.

Conclusion

Next.js is not designed to use a strict Content-Security-Policy, which may discourage many software engineers. I hope this article can help some of them who might be tempted to use the unsafe-inline keyword.

If you haven't yet selected a framework for your next secure app, consider avoiding Next.js and opting for a better-suited one, although I haven't identified it yet.

Link

Next.js: consequence of AppRouter on your CSP

0xdbe — Thu, 07 Mar 2024 15:26:02 +0000

With the integration of AppRouter, Next.js undergoes significant internal changes in component loading and management.
Underneath, AppRouter defaults to employing SSR (Server-Side Rendering) and leverages React Server Components (RSC).
However, this transition brings about consequential impacts on CSP (Content Security Policy).

This article is written down as an ADR (Architectural Decision Record) because, from my point of view, this is an important security decision.
This includes the context of how the decision was made and the consequences of adopting the decision.
So, if you find it useful, you can share this ADR with your team members, and perhaps it will prove to be an effective strategy.

Issue

All Server Components are loaded using an inline script as depicted below:

<script>
  self.__next_f.push(
    [
        1,
        "1:HL[
            \"/_next/static/media/c9a5bc6a7c948fb0-s.p.woff2\",
            \"font\",{\"crossOrigin\":\"\",
            \"type\":\"font/woff2\"}
           ]\n
         2:HL[
            \"/_next/static/css/0a4b1961022ab8f5.css\",
            \"style\"
           ]\n
         0:\"$L3\"\n
        "
    ]
    )
</script>

This script invokes self.__next_f.push() with the RSC payload, consisting of serialized HTML content.
From a security standpoint, this presents an issue due to the presence of an unsafe inline script.

Considered Options

Disable AppRouter

With create-next-app, it's always an option to create a Next.js app without AppRouter.
When prompted, select No to the following question:

Would you like to use App Router? (recommended)  No / Yes

This choice replaces the AppRouter with the old PageRouter.
However, it's worth noting that this is not recommended by Next.js, as the PageRouter may potentially be deprecated in future releases.

Disable SSR

In order to disable Server Side Rendering, add use client in each component and layout.
Unfortunately, this means forfeiting the benefits of SSR.

Use unsafe-inline

The simplest way to make AppRouter work is by adding unsafe-inline.
However, this keyword disables protection against XSS (Cross-Site Scripting).

Use nonce

Another option to allow inline script is to use a nonce.
A nonce is a unique, random string of characters created for one-time use.

This nonce must be inserted in the HTTP Header:

script-src: nonce-1234

And also in the HTML document:

<script nonce="1234">
  //...
</script>

Decision

Among the considered options, the only safe solution is to use a CSP with nonce in the script-src directive.
While nonces should generally be avoided in a CSP, Next.js doesn't currently provide any secure alternatives, and nonces are the only solution to maintain a strict CSP.

Consequence

In order to generate a random nonce for each request, a static storage solution like Bucket S3 can no longer be used to host a Next.js application.
Thus, an application runtime is now required, potentially increasing hosting costs.
Additionally, pages including a random nonce cannot be cached through a CDN (Content Delivery Network).

GitHub: How To Enable Code Scanning With Semgrep

0xdbe — Wed, 09 Nov 2022 12:52:22 +0000

Semgrep is an incredible static analysis engine that can be used for finding bugs, detecting vulnerabilities and even for enforcing code standards.
Semgrep is a Swiss army knife for static code analysis.

This article describes how to automate the discovery of coding vulnerabilities with Semgrep and GitHub Workflows.
For this, we will need 2 workflows: full scan and differential scan.

Full scan

The first workflow is dedicated to scan all the codebase of your application and provides a global analysis of the existing.

To create this workflow, paste the following content in .github/workflows/semgrep-full.yaml:

---
name: Semgrep Full Scan

on:
  workflow_dispatch:
    branches:
      - main
  schedule:
    - cron:  '0 1 * * 6'

jobs:

  semgrep-full:
      runs-on: ubuntu-latest
      container:
        image: returntocorp/semgrep

      steps:

        # step 1
        - name: clone application source code
          uses: actions/checkout@v3

        # step 2
        - name: full scan
          run: |
            semgrep \
              --sarif --output report.sarif \
              --metrics=off \
              --config="p/default"

        # step 3
        - name: save report as pipeline artifact
          uses: actions/upload-artifact@v3
          with:
            name: report.sarif
            path: report.sarif

        # step 4
        - name: publish code scanning alerts
          uses: github/codeql-action/upload-sarif@v2
          with:
            sarif_file: report.sarif
            category: semgrep

Then, you can manually trigger this workflow to run a first full scan. All findings will be published in the Code Scanning alerts in the Security tab of your GitHub repository.

This workflow is also scheduled to run a full scan every Saturday at 1:00 AM. And the result is sync with the Code Scanning Alerts dashboard. New findings are published and fixed findings are automatically closed. This is an immensely cool feature!

Code Scanning alerts is free for public repositories but organisations must subscribe to GitHub Advanced Security which is a very expensive add-on. If you don't have this option, and you don’t want to subscribe, you can use another security dashboard like Defect Dojo.

... and it’s that simple. The first workflow is now operational!

Now, you’ll probably discover that you have a lot of findings in your Code Scanning Alerts dashboard. We know that it will not be possible to fix all of them immediately. Fixing those will probably need several weeks of work. That is why this workflow can't block the software pipeline. However, thanks to this workflow, you can follow your progress because, each week, fixed alerts are automatically closed.

While waiting for these corrections, you can block all Pull Requests which could add new findings. For that, we can write a second workflow to run a differential scan in order to report only findings in the Pull Requests.

Differential scan

The second workflow is dedicated to analyse Pull Requests.

To create this workflow, paste the following content in .github/workflows/semgrep-diff.yaml:

---
name: Semgrep Differential Scan
on:
  pull_request

jobs:

  semgrep-diff:
    runs-on: ubuntu-latest
    container:
      image: returntocorp/semgrep

    steps:

      # step 1
      - name: clone application source code
        uses: actions/checkout@v3
        with:
          fetch-depth: 0

      # step 2
      - name: differential scan
        run: |
          semgrep scan \
            --error \
            --metrics=off \
            --baseline-commit ${{ github.event.pull_request.base.sha }} \
            --config="p/default"

Under the hood, Semgrep performs two scans: one on the Pull Request and another on the existing codebase before the Pull Request. Therefore, only new findings are reported.

Now, you can protect your default branch main in your repository settings, by adding semgrep-diff in Require status checks to pass before merging.
By the way, you can also check Do not allow bypassing the above settings to prevent Semgrep bypass.
After that, it will not be possible to merge thes Pull Requests with new findings:

Wrap-Up

Congratulations! You have setup Semgrep on your GitHub repository with two workflows:

A workflow to perform a full scan on the existing codebase
A workflow to perform a differential scan on Pull Request

Using Semgrep with GitHub this way provides more flexibility. As you can see, you can enable code scanning without having to fix all of the findings on your existing codebase.

Take the time to assess the risks of each finding in order to prioritise them. In the meantime, you will be sure that there will be no additional findings in your repository, and you can even change the rules without freezing any developments.

Spring Boot: Prevent Log Injection Attacks With Logback

0xdbe — Sun, 13 Mar 2022 20:46:46 +0000

Log Injection is an attack that has been known to everyone for years.
Despite the fact that any application can record logs from user input, for too long many of us had forgotten about the dangers.
But the recently discovered vulnerabilities concerning log4j2 have reminded us of the importance of preventing log injection attacks.
This article describes one concrete way - albeit not the only way - to prevent log injection attacks in a Spring Boot application using Logback.

This article is written down as an ADR (Architectural Decision Record) because, from my point of view, this is an important security decision.
This includes the context of how the decision was made and the consequences of adopting the decision.
So, if you find it useful, you can share this ADR with your team members, and perhaps it will prove to be an effective strategy.

Context

By default, a Spring Boot application uses Logback as a logging framework, and it does this with SLF4J as the interface between the application and the logging framework.

In this way, an application can easily log anything in two steps:

Create a logger with LoggerFactory.getLogger()
Log event with logger.debug() (where debug is the log level)

Here is an example that can be found in a simple greeting controller:

@RestController
public class HelloController {

    private final Logger logger = LoggerFactory.getLogger(this.getClass());

    @RequestMapping("/")
    public String index(@RequestParam(value = "name", defaultValue = "World") String name) {
        logger.debug("Hello {}", name);
        return "Hello " + name;
    }

}

As you can see, this controller takes the username as the input and then logs it.

Consequently, due to this controller logging data from user input, this application is vulnerable to log injection.

Attack

Primarily, log injection allows an attacker to forge log entries; this is what we call "log forging.” The easiest way is to forge a new log entry using CRLF injection.

CRLF injection involves inserting two control characters called Carriage Return (%0d or \r) and Line Feed (%0a or \n).

Here is an example of an CRLF injection on our greeting controller:

curl http://localhost:8080/\?name\=Marty%0d%0aYou%20have%20been%20pwned

This request results in the logging of two separate entries in the logger.
This could be annoying when later doing log analysis because there would be additional incorrect log entries.

However, despite being primarily used to forge entries, sometimes, log injection attacks can also be used to inject malicious code that could then be executed either by the logging framework (like log4j2) or later in the logging pipeline.

So, it is vital to prevent log injection attacks with a suitable defensive solution.

Considered options

There are many ways to prevent log injection attacks, such as:

Input validation involves checking that user inputs are in the expected format (mail, date, price, value from a list, ...). This is a good thing! However, for some types of data (like comments), input validation is too difficult and would not be very effective. Of course, you can keep going with input validation, but this is not enough to secure an application.
Input filtering involves stripping out unsafe characters. This is well-intentioned, but sometimes mangles perfectly good input. For example, if the filtering function strips the '', someone like O'Conor becomes OConor. Something that I doubt they would appreciate.

These solutions are not acceptable if you want to build secure software.

Decision

The best way to prevent log injection is output encoding.
It is really easy to do with Logback!

Here is the configuration file logback.xml to encode logs using json layout:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>

    <appender name="console" class="ch.qos.logback.core.ConsoleAppender">
        <encoder class="ch.qos.logback.core.encoder.LayoutWrappingEncoder">
          <layout class="ch.qos.logback.contrib.json.classic.JsonLayout">
            <jsonFormatter class="ch.qos.logback.contrib.jackson.JacksonJsonFormatter"/>
            <appendLineSeparator>true</appendLineSeparator>
          </layout>
        </encoder>
    </appender>

    <root level="info">
        <appender-ref ref="console"/>
    </root>

</configuration>

And here is the dependencies required by Logback to support JSON:

dependencies {
    implementation 'ch.qos.logback.contrib:logback-json-classic:0.1.5'
    implementation 'ch.qos.logback.contrib:logback-jackson:0.1.5'
}

With this configuration, each log entry is wrapped up in a JSON object:

{
  "timestamp":"1643015604000",
  "level":"DEBUG",
  "thread":"http-nio-8080-exec-1",
  "logger":"net.example.logging.HelloController",
  "message":"Hello Marty\r\nYou have been pwned",
  "context":"default"
}

As you can see, special characters, like CRLF, are escaped.
This will be the same for quotation marks which will be encoded by \".

Consequences

From this point onwards, this application is no longer vulnerable to log injection anymore.
However, there are consequences to consider.

Unreadable logs

Since each log entry is wrapped up in a JSON object, it becomes difficult to use logs with simple tools like cat, tail or grep.
So, a log management system, such as ELK (Elasticsearch, Logstash and Kibana), is mandatory.

However, it is still possible to have several configurations using Spring Profile in logback-spring.xml:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>

  <springProfile name="!local">
    <!-- Configuration with JSON Layout -->
  </springProfile>

  <springProfile name="local">
    <!-- Configuration with Pattern Layout -->.
  </springProfile>

</configuration>

In this case, Spring Boot Application uses the default pattern layout when it starts locally.
Thus making logs easier to read for developers.

Sensitive Data

Keep in mind that this JSON Layout doesn't mask sensitive data in log entries.
A custom layout will still be required to mask sensitive line PII.

Angular Security - Serve application locally over HTTPS

0xdbe — Thu, 09 Sep 2021 00:00:00 +0000

When you develop an Angular application, you will come to a point where you need to serve it on localhost over HTTPS. This is often the case if you need to interact with an identity provider such as Facebook, Auth0, ... And by the way, testing locally with HTTPS could be useful to detect mixed content issues that can break a production HTTPS website.

This article will walk you through setting Angular to use locally-trusted development certificate with mkcert. This is an easy way to expose an application over HTTPS without security warnings and you don't worry too much about OpenSSL.

Install mkcert

mkcert is a simple tool for making locally-trusted development certificates.
This tool is written by Filippo Valsorda, Cryptographer and Go security leader. Follow instructions on https://github.com/FiloSottile/mkcert#installation to install this tool.

Create local certificate authority

Run this command to create a new local certificate authority (CA):

mkcert -install

This command did the following:

Generate CA certificate and its key, and store them in an application data folder in the user home, such as ~/.local/share/mkcert/
Add this new certificate authority in trust stores (system, Firefox, Chrome, ...). So, all certificates issue with this CA will be trusted by your browser

Be aware that the rootCA-key.pem file that mkcert automatically generates gives complete power to intercept secure requests from your machine. So, do not share it to stay safe against MITM (Man-in-the-middle) attack.

Get certificate

Run the following commands from Angular project directory:

mkdir tls
mkcert \
      -cert-file ./tls/localhost-cert.pem \
      -key-file ./tls/localhost-key.pem \
      -ecdsa \
      localhost 127.0.0.1 ::1

This certificate will expire in 3 months. In order to make renewal easier, we can create a shortcut for this command in package.json:

{
  "scripts": {
    "start": "npm run cert & ng serve",
    "cert": "mkdir -p ./tls & mkcert -cert-file ./tls/localhost-cert.pem -key-file ./tls/localhost-key.pem -ecdsa localhost 127.0.0.1 ::1"
  }
}

Thus, you get a new certificate each time you start your application

Don't forget to add tls/*in .gitignore to prevent publication of your private key.

Serve application

In order to serve Angular application securely, add ssl, sslCert and sslKey options to serve command:

ng serve \
      --ssl=true \
      --sslCert=./tls/localhost-cert.pem \
      --sslKey=./tls/localhost-key.pem

To avoid to write these options each time that we want to run this app over HTTPS, we can set them in the angular.json file:

{
  "serve": {
    "builder": "@angular-devkit/build-angular:dev-server",
    "options": {
      "ssl": true,
      "sslCert": "tls/localhost-cert.pem",
      "sslKey": "tls/localhost-key.pem"
    }
  }
}

Like so, you can easily serve your app by using npm start and then, browse https://localhost:4200/ without security warning. But keep in mind that this could be used only for local development, not for production.

Angular Security - Disable Inline Critical CSS

0xdbe — Mon, 06 Sep 2021 20:11:22 +0000

Improving load time is crucial for the success of your application. One way to reduce this load time is to optimize the CSS loading but it is quite tricky, because CSS files are render-blocking. This means that the browser must download and parse these files before starting to render the web page.

That's why Angular provides CSS optimization in order to reduce this render-blocking delay, and at the same time, to improve the First Contentful Paint (FCP). This optimization involves first inlining critical CSS and delaying the loading of non-critical CSS.

This article describes what's wrong with this optimization and how to disable it to keep a strict CSP (Content Security Policy).

What's wrong?

Inline Critical CSS is an optimization that impacts our CSP (Content Security Policy):

style-src-elem 'unsafe-inline';    // For Inlining critical CSS
script-src     'unsafe-inline';    // For Delaying non-critical CSS

To understand why it is necessary, let's take a look at these practices.

Inlining critical CSS

During the build process, Angular extracts first all CSS resources that block the rendering. Once critical CSS are extracted, Angular inlines them directly in the index.html file. In order to authorize inline CSS, we have to add the following content in our CSP:

style-src-elem 'unsafe-inline';

With this configuration, our CSP is not able to block CSS injections anymore. This problem is not new since inline CSS is used by Angular for Component Style. So, inlining critical CSS should not further affect our CSP.

Delaying non-critical CSS

After inlining critical CSS, the rest can be postponed. However, HTML and CSS don't support asynchronous loading for CSS files. To circumvent this issue, there is an Angular trick to load non-critical CSS asynchronously using media attribute:

<link rel="stylesheet"
  href="styles.1d6c8a3b8017c43eaeda.css"
  media="print"
  onload="this.media='all'">

Media type (print) doesn’t match the current environment, so the browser decides that it is less important and loads the stylesheet asynchronously, without delaying the page rendering. On load, we change media type so that the stylesheet gets applied to screens. In order to authorize event handlers that run inline script, we have to include the following content in our CSP:

script-src 'unsafe-inline';

This configuration almost defeats the purpose of CSP, thus we could be exposed to XSS attacks.

How to fix this?

For security purposes, inline critical CSS must be disabled to keep a strict CSP.

Inline critical CSS is a new optimization introduced in Angular 11.1. However it was disabled by default. This optimization is now enabled by default in v12 and you have to set inlineCritical to false in angular.json for each configuration:

{
  "configurations": {
    "production": {
      "optimization": {
        "scripts": true,
        "styles": {
          "minify": true,
          "inlineCritical": false
        },
        "fonts": false
      }
    }
  }
}

With this configuration, Angular includes CSS as before:

<link rel="stylesheet" href="styles.css">

And we don't have to weaken our CSP!

DEV Community: 0xdbe

GitHub: signing commit in a workflow

GraphQL Mutation

Usage with gh CLI

Usage in a GitHub Workflow

Next.js: consequence of Next/Image on your CSP

Issue

Considered Options

Unsafe Inline

Unsafe Hashes

Remove Style

HTML Tag

Decision

Consequence

Links

Next.js: Crafting a Strict CSP

Requirements

Middleware

Helper functions

Step 1: Initialize Response

Step 2: Define CSP Violation Reporting

Step 3: Generate Nonce

Step 4: Generate CSP Content

Page Render

Conclusion

Link

Next.js: consequence of AppRouter on your CSP

Issue

Considered Options

Disable AppRouter

Disable SSR

Use unsafe-inline

Use nonce

Decision

Consequence

Links

GitHub: How To Enable Code Scanning With Semgrep

Full scan

Differential scan

Wrap-Up

Spring Boot: Prevent Log Injection Attacks With Logback

Context

Attack

Considered options

Decision

Consequences

Unreadable logs

Sensitive Data

Angular Security - Serve application locally over HTTPS

Install mkcert

Create local certificate authority

Get certificate

Serve application

Angular Security - Disable Inline Critical CSS

What's wrong?

Inlining critical CSS

Delaying non-critical CSS

How to fix this?