KodeKloud Notes

In this guide, we dive into Jenkins’ global security settings to help you harden your CI/CD environment. By default, Jenkins enables strong security controls—think of them as locked doors and windows. Occasionally, you might need to relax these settings for specific integrations or troubleshooting. Always revert to the recommended defaults once your tasks are complete.

We’ll cover:

Markup Formatting: Preventing XSS attacks
CSRF Protection: Defending against CSRF exploits

1. Markup Formatting

User-supplied descriptions (job descriptions, system messages, view notes) are rendered with a chosen formatter. Without proper controls, malicious users could inject HTML or scripts, leading to cross-site scripting vulnerabilities.

Formatter Option	Description	Tags Allowed
Plain text (default)	Safest choice: escapes all HTML so it renders literally as text.	None
Safe HTML	Allows a small, sanitized subset of HTML for basic styling.	`<b>`, `<i>`, `<u>`, `<p>`, etc.
Custom formatters (via plugins)	Richer formatting; requires careful plugin selection and review.	Varies by plugin

The image is an infographic about markup formatting, highlighting security concerns like XSS attacks and suggesting security measures such as using plain text, safe HTML, and custom formatters in Jenkins.

1.1 Plain Text Formatter

With Plain text, all markup is escaped:

<p>Welcome to <strong><span style="color: rgb(235, 107, 86);">KodeKloud</span></strong> Jenkins Controller</p>
<script>alert('XSS');</script>

Renders as:

<p>Welcome to <strong><span style="color: rgb(235, 107, 86);">KodeKloud</span></strong> Jenkins Controller</p>
<script>alert('XSS');</script>

Note

Plain text is ideal for high-security environments where formatting isn’t required.

1.2 Safe HTML Formatter

The Safe HTML option strips unsafe elements (like <script>) but lets through simple styling tags:

<p>Welcome to <strong><span style="color: rgb(235, 167, 86);">KodeKloud</span></strong> Jenkins Controller</p>
<script>alert('XSS');</script>

Renders as: Welcome to KodeKloud Jenkins Controller

Warning

Even with Safe HTML, avoid embedding untrusted content. Review any custom tags allowed by your HTML sanitizer.

2. CSRF (Cross-Site Request Forgery) Protection

CSRF attacks trick authenticated users into submitting unintended requests—triggering builds, deleting artifacts, or changing settings without consent.

2.1 How CSRF Works

Attacker crafts a malicious link or form targeting a Jenkins endpoint.
Authenticated user clicks the link while logged into Jenkins.
Jenkins executes the request under the user’s credentials, unaware it wasn’t initiated from the UI.

The image illustrates a CSRF (Cross-Site Request Forgery) attack process involving a hacker embedding a request in a hyperlink, which a logged-in Jenkins user clicks, leading to unauthorized actions on the Jenkins server.

2.2 Enabling Crumb-Based Protection

Jenkins defends against CSRF by issuing a crumb (token) for every form and state-changing API call. Requests missing a valid crumb are rejected.

Enable CSRF Protection
In Manage Jenkins > Configure Global Security, ensure “Prevent Cross Site Request Forgery exploits” is checked. Jenkins will use the default crumb issuer or a custom implementation.
Educate Users
Remind team members to avoid clicking unknown links while logged into Jenkins.

By default, crumb protection is enabled in Jenkins—keep it that way.

The image is about CSRF protection in Jenkins, showing a configuration panel for a "Crumb Issuer" and explaining its use in form submissions and API calls. It includes an illustration of the Jenkins mascot and a special token labeled "crumb."

Watch Video

Watch video content

Global Security Settings