Last updated: 10th July 2026 for CC Security Essentials version 1.0

Introduction

CC Security Essentials provides a deliberately selected set of actions and filters for developers who need to integrate custom functionality with the plugin.

These extension points allow custom plugins and website-specific code to:

initialise after CC Security Essentials has loaded;
add compatible security modules;
contribute Security Health checks and recommendations;
provide custom verification results;
accommodate public REST API routes;
respond to blocked REST API requests;
extend selected administrator summaries;
add useful information to diagnostic reports.

This guide explains how to use the supported developer API safely and maintainably.

If you are using CC Security Essentials without developing a custom integration, you will not normally need this guide.

Supported Developer API

The supported developer API currently consists of:

Actions, which allow custom code to respond when events occur;
Filters, which allow selected values and behaviour to be modified.

Only extension points documented within the developer documentation should be treated as supported public APIs.

The source code may contain additional hooks used for internal integration or interface construction. These are not part of the supported developer API and may change without notice.

Developer Documentation

Actions Reference

The Actions Reference documents the supported events to which custom code can respond.

These include:

plugin lifecycle events;
administrator summary extension points;
blocked REST API visitor requests.

Use an action when you want custom code to perform additional work without changing a value used by the plugin.

Filters Reference

The Filters Reference documents the values and behaviour that can be modified.

These include:

module registration;
default and recommended settings;
import and export processing;
feature metadata;
Security Health checks;
Protection Score weighting;
recommendations;
verification;
compatibility guidance;
REST API protection;
diagnostic reports.

Use a filter when you need to modify or return a value.

Before You Begin

Developers extending CC Security Essentials should be familiar with:

WordPress actions and filters;
plugin development;
capability checks;
nonce verification;
sanitisation and validation;
output escaping;
WordPress internationalisation;
the WordPress Coding Standards.

Custom integrations become part of the website’s security environment. They should therefore follow the same security, privacy and accessibility standards expected of any well-maintained WordPress plugin.

Create a Separate Plugin

Custom code should normally be placed in a separate plugin.

Do not edit CC Security Essentials directly.

Changes made to the plugin’s files:

will be overwritten by updates;
make troubleshooting more difficult;
complicate compatibility testing;
may prevent future updates from applying cleanly.

A small integration plugin provides a cleaner and more maintainable solution.

A basic integration might use the following structure:

my-ccse-integration/
├── my-ccse-integration.php
├── includes/
│   ├── class-plugin.php
│   └── class-security-check.php
├── languages/
└── readme.txt

A separate plugin also keeps custom functionality active when the website changes theme.

Basic Integration Example

The following example waits until CC Security Essentials has completed loading:

<?php
/**
 * Plugin Name: My CC Security Essentials Integration
 * Description: Example integration with CC Security Essentials.
 * Version:     1.0.0
 * Text Domain: my-ccse-integration
 */

defined( 'ABSPATH' ) || exit;

add_action(
    'ccse_loaded',
    function ( $plugin ) {
        // Initialise the custom integration.
    },
    10,
    1
);

For most integrations, ccse_loaded is the appropriate lifecycle action.

Earlier lifecycle actions should be used only when custom code genuinely needs to participate in the plugin’s initialisation process.

Choosing Between an Action and a Filter

Requirement	Use
Respond after the plugin loads	Action
Respond when a REST request is blocked	Action
Add content to a supported administrator summary	Action
Add or modify a Security Health check	Filter
Add a verification result	Filter
Permit a public REST API request	Filter
Modify an exported settings file	Filter
Add information to a diagnostic report	Filter

An action performs additional work.

A filter receives a value and must return a value.

Common Integration Patterns

Initialise After the Plugin Loads

Use ccse_loaded for general integration setup:

add_action(
    'ccse_loaded',
    function ( $plugin ) {
        my_ccse_integration_start();
    },
    10,
    1
);

Add a Custom Module

Use ccse_modules to register a compatible module object:

add_filter(
    'ccse_modules',
    function ( $modules ) {
        $modules[] = new \MyPlugin\SecurityModule();

        return $modules;
    }
);

The module must provide a public register_hooks() method.

Add a Security Health Check

A complete custom check may use several filters:

ccse_feature_metadata;
ccse_status_checks;
ccse_status_check_weights;
ccse_recommendations;
ccse_verify_check.

Each filter handles a different part of the feature.

An extension should use only the filters it genuinely needs.

Allow a Public REST API Route

For a route prefix:

add_filter(
    'ccse_rest_allowed_route_prefixes',
    function ( $prefixes ) {
        $prefixes[] = '/my-plugin/v1/public/';

        return $prefixes;
    }
);

For precise control over an individual request:

add_filter(
    'ccse_rest_public_request_allowed',
    function ( $allowed, $route, $method ) {
        if (
            '/my-plugin/v1/availability' === $route
            && 'GET' === $method
        ) {
            return true;
        }

        return $allowed;
    },
    10,
    3
);

Public exceptions should be kept as narrow as possible.

Respond to a Blocked REST Request

Use ccse_rest_visitor_request_blocked:

add_action(
    'ccse_rest_visitor_request_blocked',
    function ( $route, $method ) {
        // Perform lightweight, privacy-conscious processing.
    },
    10,
    2
);

This action may fire frequently during automated activity. Avoid expensive processing or unlimited logging.

Security Requirements

Custom integrations should follow standard WordPress security practices.

Validate Capabilities

Before performing privileged administration tasks:

if ( ! current_user_can( 'manage_options' ) ) {
    return;
}

Verify Nonces

Any custom form or state-changing request should use an appropriate nonce.

Sanitise Input

Treat submitted, imported and request-derived values as untrusted.

Use the appropriate WordPress sanitisation function for each value.

Escape Output

Escape all dynamic output at the point where it is rendered.

Common functions include:

esc_html();
esc_attr();
esc_url();
wp_kses_post() where restricted HTML is intentionally permitted.

Avoid Exposing Security Details

Administrator interfaces and visitor-facing error messages should not reveal unnecessary information about:

website configuration;
account validity;
authentication;
filesystem paths;
server internals;
security rules.

Privacy Requirements

Some extension points can expose request information or allow custom logging.

In particular:

ccse_rest_visitor_request_blocked;
ccse_diagnostic_report;
import and export filters;
custom verification callbacks.

Integrations should:

collect only information that is genuinely required;
avoid storing complete request objects;
avoid storing passwords, tokens or request bodies;
limit how long records are retained;
provide a way to remove information where appropriate;
restrict access to authorised administrators;
ensure the website’s privacy information remains accurate.

The fact that information is security-related does not remove the need to handle it proportionately.

Performance Requirements

Security-related hooks may run on frequently requested parts of a website.

Callbacks should therefore:

return quickly when no work is required;
avoid unnecessary database queries;
avoid synchronous external requests;
avoid repeatedly loading large files or libraries;
place limits on stored logs;
defer substantial work where practical.

For example, do not send an external notification synchronously for every blocked automated REST request.

Where substantial processing is required, store the minimum information necessary and process it through an appropriate background mechanism.

Accessibility

Custom administrator output should follow WordPress accessibility practices.

This includes:

semantic headings;
meaningful field labels;
keyboard-accessible controls;
visible focus indicators;
sufficient colour contrast;
status information that does not rely on colour alone;
clear validation and error messages.

When using the administrator-interface actions, custom output becomes part of the CC Security Essentials interface and should provide a consistent experience.

Internationalisation

All user-facing or administrator-facing text should be translation-ready.

For example:

$message = __(
    'The custom protection is operating correctly.',
    'my-plugin'
);

Avoid constructing sentences from separately translated fragments.

Provide translator comments where placeholders or context may not be obvious.

Defensive Development

Custom integrations should behave safely when:

CC Security Essentials is inactive;
an expected feature is unavailable;
another plugin modifies the same filtered value;
a callback receives unexpected data;
the website is using only the core plugin;
the WordPress administration area is not being loaded.

Check classes, functions and values before using them.

For example:

if ( ! class_exists( '\WP_REST_Request' ) ) {
    return;
}

Avoid assuming that your callback is the only callback attached to a filter.

Always preserve the value supplied by earlier callbacks unless you have a clear reason to replace it.

Use Unique Identifiers

Custom settings, checks and recommendations should use identifiers that are unlikely to conflict with other plugins.

For example:

$checks['mycompany_custom_protection'] = [
    // Check definition.
];

Avoid generic identifiers such as:

$checks['security'] = [];

A suitable prefix based on the extension or organisation name reduces the chance of collisions.

Do Not Rely on Internal Objects

Some documented actions provide plugin or service objects as context.

Only documented methods and behaviour should be relied upon.

Do not assume that:

internal class constructors will remain unchanged;
undocumented methods will remain available;
internal properties will remain public;
objects will always be created in the same order.

Where a documented filter or action provides the required integration point, use it instead of calling internal methods directly.

Compatibility with Other Extensions

Multiple plugins may use the same public filters.

A well-behaved callback should:

preserve existing array entries;
avoid resetting complete collections unnecessarily;
use unique keys;
return the supplied value when no change is required;
avoid assuming it runs first or last.

For example:

add_filter(
    'ccse_recommendations',
    function ( $recommendations ) {
        if ( ! is_array( $recommendations ) ) {
            $recommendations = [];
        }

        $recommendations[] = my_plugin_build_recommendation();

        return $recommendations;
    }
);

Changing callback priority should be necessary only where a genuine ordering dependency exists.

Testing an Integration

Before deploying custom code to a live website:

Test with the current supported WordPress version.
Test with the current CC Security Essentials release.
Test while signed in and signed out where relevant.
Test administrator and visitor-facing requests.
Test both enabled and disabled core features.
Review PHP and WordPress debug logs.
Run relevant Verification checks.
Review Security Health and Diagnostics.
Confirm that custom output remains accessible.
Confirm that stored information follows an appropriate retention policy.

Where possible, repeat testing on both a development website and a representative staging copy.

Updating an Integration

After updating CC Security Essentials:

review the release notes;
test the integration on a staging website;
rerun relevant Verification checks;
review the Security Overview and Security Health;
confirm that REST API exceptions remain appropriately limited;
check that custom administrator output still displays correctly.

Documented APIs are intended to remain stable during the 1.x release series, but testing remains an important part of responsible plugin maintenance.

Unsupported Approaches

Avoid:

editing CC Security Essentials files;
using undocumented hooks;
calling private or undocumented methods;
altering plugin database options directly without the documented filters;
removing core protections without clear administrator consent;
suppressing plugin administration information through undocumented interfaces;
storing unlimited security-event history;
exposing complete REST request data;
displaying disruptive promotional content within the plugin’s pages.

These approaches may create security, privacy, compatibility or maintenance problems.

API Stability

The documented developer API is intended to remain stable throughout the CC Security Essentials 1.x release series wherever practical.

If an extension point must change:

a replacement will normally be introduced first;
the existing interface will normally be deprecated before removal;
significant changes will be described in release notes;
backwards compatibility will be preserved where practical.

Undocumented behaviour remains subject to change.

Requesting an Extension Point

A particular integration may require functionality that is not currently available through the documented API.

Rather than depending on an undocumented hook or modifying plugin files, contact support with:

the behaviour you are trying to achieve;
why the existing actions and filters are insufficient;
an example use case;
any security or privacy considerations;
whether the requirement could benefit other developers.

A narrowly designed extension point may then be considered for a future release.

Continue with:

Developer Guide

Introduction

Supported Developer API

Developer Documentation

Actions Reference

Filters Reference

Before You Begin

Create a Separate Plugin

Basic Integration Example

Choosing Between an Action and a Filter

Common Integration Patterns

Initialise After the Plugin Loads

Add a Custom Module

Add a Security Health Check

Allow a Public REST API Route

Respond to a Blocked REST Request

Security Requirements

Validate Capabilities

Verify Nonces

Sanitise Input

Escape Output

Avoid Exposing Security Details

Privacy Requirements

Performance Requirements

Accessibility

Internationalisation

Defensive Development

Use Unique Identifiers

Do Not Rely on Internal Objects

Compatibility with Other Extensions

Testing an Integration

Updating an Integration

Unsupported Approaches

API Stability

Requesting an Extension Point

Related Articles