Custom rule examples

Not sure what to write a rule for? Below are some common questions, ideas, and topics to spur your imagination. Happy hacking! 💡

Use cases

Automate code review comments

Time to write this rule: 5 minutes

You can use Semgrep and its GitHub integration to automate PR comments that you frequently make in code reviews. Writing a custom rule for the code pattern you want to target is usually straightforward. If you want to understand the Semgrep syntax, see the documentation or try the tutorial.

A reviewer writes a Semgrep rule and adds it to an organization-wide policy.

Ban dangerous APIs

Time to write this rule: 5 minutes

Semgrep can be used to detect dangerous APIs present in code. If integrated into CI/CD pipelines, Semgrep can be used to block merges or flag for review when someone adds these dangerous APIs. For example, a rule that detects React's dangerouslySetInnerHTML looks like this.

Exempting special cases of dangerous APIs

Time to write this rule: 5 minutes

If you have a legitmate use case for a dangerous API, you can exempt a specific use of the API using a nosemgrep comment. The rule below checks for React's dangerouslySetInnerHTML, but the code is annotated with a nosemgrep comment. Semgrep will not detect this line. This allows Semgrep to continuously check for future uses of dangerouslySetInnerHTML while allowing for this specific use.

Detect security violations

Time to write this rule: 5 minutes

Semgrep can be used to flag specific uses of APIs too, not just the presence of them. We jokingly call these the "security off" buttons and make extensive use of Semgrep to detect them.

This rule detects when HTML autoescaping is explicitly disabled for a Django template.

Scan configuration files using JSON, YAML, or Generic pattern matching

Time to write this rule: 10 minutes

Semgrep natively supports JSON and YAML and can be used to write rules for configuration files. This rule checks for skipped TLS verification in Kubernetes clusters.

The Generic pattern matching mode is for languages and file formats that Semgrep does not natively support. For example, you can write rules for Dockerfiles using the generic mode. The Dockerfile rule below checks for invalid port numbers.

Enforce authentication patterns

Time to write this rule: 15 minutes

If a project has a "correct" way of doing authentication, Semgrep can be used to enforce this so that authentication mishaps do not happen. In the example below, this Flask app requires an authentication decorator on all routes. The rule detects routes that are missing authentication decorators. If deployed in CI/CD pipelines, Semgrep can block undecorated routes or flag a security member for further investigation.

Systematize project-specific coding patterns

Time to write this rule: 10 minutes

Semgrep can be used to automate institutional knowledge. This has several benefits, including teaching new members about coding patterns in an automatic way and keeping a project up-to-date with coding patterns. If you keep coding guidelines in a document, converting these into Semgrep rules is a great way to free developers from having to remember all the guidelines.

In this example, a legacy API requires calling verify_transaction(t) before calling make_transaction(t). The Semgrep rule below detects when these methods are not called correctly.

Extract information with metavariables

Time to write this rule: 15 minutes

Semgrep metavariables can be used as output in the message key. This can be used to extract and collate information about a codebase. Click through to this example which extracts Java Spring routes. This can be used to quickly see all the exposed routes of an application.

Burn down deprecated APIs

Time to write this rule: 5 minutes

Semgrep can detect deprecated APIs just as easily as dangerous APIs. Identifying deprecated API calls can help an application migrate to current or future versions.

This rule example detects a function that is deprecated as of Django 4.0.

Promote secure alternatives

Time to write this rule: 5 minutes

Some libraries or APIs have safe alternatives, such as Google's re2, an implementation of the standard re interface that ships with Python that is resistant to regular expression denial-of-service. This rule detects use of re and recommends re2 as a safe alernative with the same interface.

Prompts for writing custom rules

Try answering these questions to uncover important rules for your project.

1. From recent post mortems: what code issues contributed to it?
2. [XYZ] is a (security, performance, other) library that everyone should use, but they don’t consistently.
3. When you review code, what changes do you frequently ask for?
4. What vulnerability classes from bug bounty submissions reoccur (or appear in different places of the codebase)?
5. Are there eng / perf patterns? Consistent exception handlers?
6. What issues were caused by misconfigurations in Infrastructure-as-Code files (JSON)?
7. What are some “invariants” that should hold about your code - things that should always or never be true (e.g. every admin route checks if user is admin)?
8. What methods/APIs are deprecated and you’re trying to move away from?