{"id":4977,"date":"2026-10-02T23:03:03","date_gmt":"2026-10-02T17:33:03","guid":{"rendered":"https:\/\/cpanelfree.com\/blog\/setting-up-nginx-with-modsecurity-web-application-firewall-waf\/"},"modified":"2026-10-02T23:03:03","modified_gmt":"2026-10-02T17:33:03","slug":"setting-up-nginx-with-modsecurity-web-application-firewall-waf","status":"publish","type":"post","link":"https:\/\/cpanelfree.com\/blog\/setting-up-nginx-with-modsecurity-web-application-firewall-waf\/","title":{"rendered":"Setting Up Nginx with ModSecurity Web Application Firewall (WAF)"},"content":{"rendered":"

Modern web applications face relentless automated scanning, distributed Layer-7 injection exploits, and zero-day vulnerabilities that bypass conventional network-layer packet filters. Integrating an intelligent, open-source Web Application Firewall (WAF) directly into the reverse proxy edge allows engineering teams on CpanelFree<\/a> to inspect incoming HTTP payloads and terminate malicious requests before they consume precious backend runtime cycles. In this architectural deep dive, we examine how to compile, configure, and optimize an enterprise nginx modsecurity setup<\/strong> utilizing libmodsecurity3 and the OWASP Core Rule Set (CRS) v4 for maximum threat mitigation with sub-millisecond processing latency.<\/p>\n

<\/p>\n

Understanding the Nginx and ModSecurity v3 (libmodsecurity) Architecture<\/h2>\n
\n

Direct Answer:<\/strong> An enterprise nginx modsecurity setup<\/strong> couples the standalone C++ libmodsecurity<\/code> engine with Nginx via a dynamic connector module (ngx_http_modsecurity_module.so<\/code>). Working alongside the OWASP Core Rule Set (CRS), it provides deep Layer-7 HTTP inspection, real-time threat mitigation against the OWASP Top 10, anomaly scoring, and non-blocking event-driven traffic scrubbing without degrading backend response latency.<\/p>\n<\/div>\n

Deploying a Web Application Firewall in front of modern web microservices or legacy PHP runtimes requires an architectural compromise between inspection depth and connection throughput. Historically, ModSecurity v2 was engineered as an in-process module tightly coupled to the Apache HTTP Server request lifecycle, relying heavily on the Apache Portable Runtime (APR). Attempting to run ModSecurity v2 on Nginx required an intrusive emulation wrapper that undermined Nginx\u2019s asynchronous, non-blocking event loop by introducing blocking I\/O calls during request parsing.<\/p>\n

The introduction of ModSecurity v3 (libmodsecurity)<\/strong> fundamentally redesigned this paradigm. Libmodsecurity is a standalone C++ library that encapsulates the complete rule evaluation engine, regular expression parsers, transformation functions, and transaction state machines into an independent interface. Nginx interfaces with this engine using a lightweight, dynamic connector module: ModSecurity-nginx<\/code> (compiled as ngx_http_modsecurity_module.so<\/code>). When an incoming HTTP request hits an Nginx worker, the connector intercepts the stream at designated request phases, hands pointers to the header and body buffers over to libmodsecurity, and evaluates security policies without thread stalling.<\/p>\n

\n

Architecture Note:<\/strong> ModSecurity v3 separates the parsing library from the web server runtime. In an Nginx deployment, Nginx manages network sockets, TLS termination, and request pipelining, while libmodsecurity<\/code> runs in-memory inspection routines. Linking Nginx with PCRE JIT (Just-In-Time) compilation enables hardware-accelerated pattern matching, drastically cutting rule evaluation cycles across multi-core systems.<\/p>\n<\/blockquote>\n

ModSecurity Architectural Modes & Engine Performance Metrics<\/h2>\n

Selecting the correct inspection posture and tuning buffer allocation dictates whether your edge proxy sustains high traffic or collapses under CPU starvation. The following matrix illustrates key performance metrics, kernel interactions, and memory behaviors between an unoptimized default installation and a tuned enterprise production configuration.<\/p>\n

\n\n\n\n\n\n\n\n\n\n\n
Feature \/ Metric<\/th>\nStandard \/ Default<\/th>\nTuned \/ Production<\/th>\n<\/tr>\n<\/thead>\n
Per-Request Latency Overhead<\/td>\n14.5 ms – 22.0 ms<\/td>\n1.4 ms – 2.6 ms<\/td>\n<\/tr>\n
Response Body Inspection (SecResponseBodyAccess)<\/td>\nOn (High CPU & Buffering)<\/td>\nOff (40%+ CPU Reduction)<\/td>\n<\/tr>\n
Regex Engine Execution<\/td>\nInterpreted PCRE<\/td>\nPCRE JIT Compiled Engine<\/td>\n<\/tr>\n
Request Body In-Memory Limit<\/td>\n131072 KB (Spools to Disk)<\/td>\n262144 KB (Zero Disk I\/O)<\/td>\n<\/tr>\n
Audit Logging Strategy<\/td>\nSynchronous Serial File I\/O<\/td>\nRelevantOnly Pipe \/ Asynchronous<\/td>\n<\/tr>\n
Worker Throughput Ceiling<\/td>\n~2,200 req\/sec per worker<\/td>\n~18,500 req\/sec per worker<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n

Step 1: Compiling libmodsecurity3 and the Nginx Dynamic Connector<\/h2>\n

While some Linux distributions distribute packaged binaries for ModSecurity, enterprise production deployments require compiling libmodsecurity3<\/code> and the Nginx connector directly against your exact Nginx binary. This guarantees compatibility with your compiler flags, OpenSSL version, and CPU architecture optimizations.<\/p>\n

First, install the essential compilation toolchains and prerequisite development libraries on your Debian\/Ubuntu or Enterprise Linux host:<\/p>\n

# Install build dependencies on Ubuntu\/Debian\napt-get update && apt-get install -y \\\n    build-essential \\\n    git \\\n    automake \\\n    autoconf \\\n    libtool \\\n    libpcre2-dev \\\n    libpcre3-dev \\\n    libxml2 \\\n    libxml2-dev \\\n    libyajl-dev \\\n    libgeoip-dev \\\n    libcurl4-openssl-dev \\\n    zlib1g-dev \\\n    libssl-dev\n\n# Clone and compile libmodsecurity v3\ncd \/usr\/local\/src\ngit clone --depth 1 -b v3\/master https:\/\/github.com\/owasp-modsecurity\/ModSecurity.git\ncd ModSecurity\ngit submodule init && git submodule update\n.\/build.sh\n.\/configure --with-pcre-jit\nmake -j$(nproc)\nmake install\nldconfig<\/code><\/pre>\n
Once libmodsecurity<\/code> is installed in \/usr\/local\/modsecurity<\/code>, compile the dynamic connector module against the exact version of Nginx installed on your system:<\/p>\n
# Query active Nginx version and compiler arguments\nNGINX_VERSION=$(nginx -v 2>&1 | awk -F'\/' '{print $2}')\ncd \/usr\/local\/src\ngit clone --depth 1 https:\/\/github.com\/owasp-modsecurity\/ModSecurity-nginx.git\nwget http:\/\/nginx.org\/download\/nginx-${NGINX_VERSION}.tar.gz\ntar -zxvf nginx-${NGINX_VERSION}.tar.gz\ncd nginx-${NGINX_VERSION}\n\n# Configure with dynamic module compatibility\n.\/configure --with-compat --add-dynamic-module=\/usr\/local\/src\/ModSecurity-nginx\nmake modules\n\n# Deploy the compiled shared object module\nmkdir -p \/etc\/nginx\/modules\ncp objs\/ngx_http_modsecurity_module.so \/etc\/nginx\/modules\/\nchmod 644 \/etc\/nginx\/modules\/ngx_http_modsecurity_module.so<\/code><\/pre>\n
Step 2: Hardening ModSecurity Core Directives for Production<\/h2>\n
Default configuration templates shipped with security software prioritize maximum visibility over server stability. In a high-traffic production environment, improperly configured body limits or response inspection will trigger cascading worker memory exhaustion (OOM kills) and excessive disk thrashing. We must construct a hardened, production-ready configuration in \/etc\/nginx\/modsec\/modsecurity.conf<\/code>.<\/p>\n
# Create directory structure for rules, audit logs, and temporary storage\nmkdir -p \/etc\/nginx\/modsec\nmkdir -p \/var\/log\/nginx\/modsec\nmkdir -p \/var\/cache\/modsecurity\/tmp\nchown -R www-data:www-data \/var\/cache\/modsecurity \/var\/log\/nginx\/modsec\n\n# Pull recommended configuration baseline\ncp \/usr\/local\/src\/ModSecurity\/modsecurity.conf-recommended \/etc\/nginx\/modsec\/modsecurity.conf\ncp \/usr\/local\/src\/ModSecurity\/unicode.mapping \/etc\/nginx\/modsec\/<\/code><\/pre>\n
Now apply tuned memory and engine parameters directly to \/etc\/nginx\/modsec\/modsecurity.conf<\/code>:<\/p>\n
# ====================================================================\n# Production ModSecurity Engine Configuration (\/etc\/nginx\/modsec\/modsecurity.conf)\n# ====================================================================\nSecRuleEngine On\n\n# Request Body Handling & Memory Safety Limits\nSecRequestBodyAccess On\nSecRequestBodyLimit 13107200\nSecRequestBodyNoFilesLimit 131072\nSecRequestBodyInMemoryLimit 262144\nSecRequestBodyLimitAction Reject\n\n# Response Body Handling (Disabled for 40%+ Latency Improvement)\nSecResponseBodyAccess Off\nSecResponseBodyMimeType text\/plain text\/html text\/xml\nSecResponseBodyLimit 1048576\nSecResponseBodyLimitAction ProcessPartial\n\n# Filesystem and Cache Isolation\nSecTmpDir \/var\/cache\/modsecurity\/tmp\/\nSecDataDir \/var\/cache\/modsecurity\/data\/\n\n# High-Performance Audit Logging Strategy\nSecAuditEngine RelevantOnly\nSecAuditLogRelevantStatus \"^(?:5|4(?!04))\"\nSecAuditLogParts ABIJDEFHZ\nSecAuditLogType Serial\nSecAuditLog \/var\/log\/nginx\/modsec\/modsec_audit.log\n\n# PCRE Execution Limits to Prevent Regex DoS (ReDoS)\nSecPcreMatchLimit 500000\nSecPcreMatchLimitRecursion 500000<\/code><\/pre>\n
\n
Architecture Note:<\/strong> Setting SecResponseBodyAccess Off<\/code> is one of the highest-yield optimizations in an enterprise WAF. Unless your compliance posture (such as PCI-DSS requirement 6.5) mandates outbound Data Leakage Prevention (DLP) for unencrypted credit card numbers, inspecting egress HTML\/JSON forces Nginx to buffer full upstream responses in memory before flushing them to clients, destroying Time to First Byte (TTFB) and HTTP\/2 stream multiplexing.<\/p>\n<\/blockquote>\n
Step 3: Integrating the OWASP Core Rule Set (CRS v4.x)<\/h2>\n
A WAF engine is inert without an authoritative threat intelligence dataset. The OWASP Core Rule Set (CRS) v4<\/strong> provides industry-standard generic attack detection rules designed to neutralize SQL Injection (SQLi), Cross-Site Scripting (XSS), Local\/Remote File Inclusion (LFI\/RFI), Remote Code Execution (RCE), and Protocol Violations.<\/p>\n
Deploy CRS v4 into the ModSecurity configuration hierarchy:<\/p>\n
# Clone the latest stable release of OWASP CRS v4\ncd \/etc\/nginx\/modsec\ngit clone --depth 1 -b v4.0\/master https:\/\/github.com\/coreruleset\/coreruleset.git owasp-crs\n\n# Initialize the CRS setup file\ncp owasp-crs\/crs-setup.conf.example owasp-crs\/crs-setup.conf<\/code><\/pre>\n
Next, assemble the master rule orchestrator file at \/etc\/nginx\/modsec\/main.conf<\/code>. This file controls the sequence in which engine rules, application exclusions, the CRS baseline, and rule checks are loaded:<\/p>\n
# ====================================================================\n# Master ModSecurity Orchestrator (\/etc\/nginx\/modsec\/main.conf)\n# ====================================================================\n\n# 1. Base Engine Directives\nInclude \/etc\/nginx\/modsec\/modsecurity.conf\n\n# 2. Pre-CRS Application Exclusions (WordPress, APIs, Nextcloud)\nInclude \/etc\/nginx\/modsec\/rules\/before-crs\/*.conf\n\n# 3. OWASP CRS Initialization & Anomaly Thresholds\nInclude \/etc\/nginx\/modsec\/owasp-crs\/crs-setup.conf\n\n# 4. OWASP CRS Rule Definitions\nInclude \/etc\/nginx\/modsec\/owasp-crs\/rules\/*.conf\n\n# 5. Post-CRS Custom Local Overrides\nInclude \/etc\/nginx\/modsec\/rules\/after-crs\/*.conf<\/code><\/pre>\n
Now, link the dynamic module into \/etc\/nginx\/nginx.conf<\/code> and enable ModSecurity inside your virtual host blocks:<\/p>\n
# Top of \/etc\/nginx\/nginx.conf\nload_module modules\/ngx_http_modsecurity_module.so;\n\nhttp {\n    # Global HTTP directives...\n    include       \/etc\/nginx\/mime.types;\n    default_type  application\/octet-stream;\n\n    # Virtual Host Configuration (\/etc\/nginx\/conf.d\/production_app.conf)\n    server {\n        listen 443 ssl http2;\n        server_name api.example.com;\n\n        ssl_certificate \/etc\/letsencrypt\/live\/api.example.com\/fullchain.pem;\n        ssl_certificate_key \/etc\/letsencrypt\/live\/api.example.com\/privkey.pem;\n\n        # Activate ModSecurity for this virtual host\n        modsecurity on;\n        modsecurity_rules_file \/etc\/nginx\/modsec\/main.conf;\n\n        location \/ {\n            proxy_pass http:\/\/127.0.0.1:8080;\n            proxy_set_header Host $host;\n            proxy_set_header X-Real-IP $remote_addr;\n            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;\n            proxy_set_header X-Forwarded-Proto $scheme;\n        }\n    }\n}<\/code><\/pre>\n
Step 4: Linux Kernel and OS Tuning for High-Concurrency WAF Ingestion<\/h2>\n
When an Nginx instance inspects multi-megabyte payloads under sustained traffic, standard Linux kernel default socket queues and connection-tracking tables will overflow. This causes silent TCP packet drops (TCP SYN retransmissions) and synthetic 502\/504 Bad Gateway errors that are frequently misdiagnosed as upstream application crashes.<\/p>\n
Deploy the following production kernel configuration to \/etc\/sysctl.d\/99-waf-performance.conf<\/code> to elevate connection backlogs, optimize TCP memory buffers, and accelerate socket recycling:<\/p>\n
# ====================================================================\n# Enterprise WAF Network & Memory Kernel Tuning (\/etc\/sysctl.d\/99-waf-performance.conf)\n# ====================================================================\n\n# Socket Queue Capacity & SYN Flood Mitigation\nnet.core.somaxconn = 65535\nnet.ipv4.tcp_max_syn_backlog = 65535\nnet.core.netdev_max_backlog = 32768\n\n# Ephemeral Port Allocation & Socket Reuse\nnet.ipv4.ip_local_port_range = 1024 65535\nnet.ipv4.tcp_tw_reuse = 1\nnet.ipv4.tcp_fin_timeout = 15\n\n# Buffer Memory Scaling for Deep Payload Inspection\nnet.core.rmem_default = 262144\nnet.core.wmem_default = 262144\nnet.core.rmem_max = 16777216\nnet.core.wmem_max = 16777216\nnet.ipv4.tcp_rmem = 4096 87380 16777216\nnet.ipv4.tcp_wmem = 4096 65536 16777216\n\n# System-Wide File Descriptor Limits\nfs.file-max = 2097152\nfs.inotify.max_user_watches = 524288<\/code><\/pre>\n
Apply the parameters immediately without rebooting via sysctl --system<\/code>. Next, lift systemd service-level descriptor ceilings by creating an override directory at \/etc\/systemd\/system\/nginx.service.d\/override.conf<\/code>:<\/p>\n
[Service]\nLimitNOFILE=1048576\nLimitNPROC=512000\nTasksMax=infinity<\/code><\/pre>\n
Reload the systemd daemon and restart Nginx: systemctl daemon-reload && systemctl restart nginx<\/code>. For mission-critical production clusters running heavy e-commerce, banking, or multi-tenant hosting workloads, provisioning on bare-metal NVMe with dedicated hardware threads is essential. Deploying your edge infrastructure on MeraHost Enterprise Cloud<\/a> guarantees pure NVMe I\/O throughput and pre-optimized server kernels, ensuring your WAF rules execute with zero CPU throttling or neighbor contention.<\/p>\n
Step 5: Testing WAF Rules, Analyzing Audit Logs, and Eliminating False Positives<\/h2>\n
With configuration files deployed, validate your syntax prior to reload: nginx -t<\/code>. Once confirmed, initiate synthetic Layer-7 attack vectors against your server to verify that ModSecurity and OWASP CRS actively intercept malicious payloads with HTTP 403 Forbidden responses.<\/p>\n
# Test 1: Simulated SQL Injection Attack\ncurl -i -s \"https:\/\/api.example.com\/?id=1%20UNION%20SELECT%20null,username,password%20FROM%20users\"\n\n# Expected Output:\nHTTP\/1.1 403 Forbidden\nServer: nginx\nContent-Type: text\/html\n\n# Test 2: Simulated Malicious Scanner User-Agent\ncurl -i -s -H \"User-Agent: Nikto\" \"https:\/\/api.example.com\/\"\n\n# Expected Output:\nHTTP\/1.1 403 Forbidden<\/code><\/pre>\n
When an attack is terminated, ModSecurity logs the transaction to \/var\/log\/nginx\/modsec\/modsec_audit.log<\/code>. Reviewing the log structure allows sysadmins to identify the specific rule ID, anomaly score, and parameter that caused the block:<\/p>\n
---0a1b2c3d-A--\n[02\/Oct\/2026:14:20:15 +0000] 198.51.100.42 54320 203.0.113.10 443\n---0a1b2c3d-B--\nGET \/?id=1%20UNION%20SELECT%20null,username,password%20FROM%20users HTTP\/1.1\nHost: api.example.com\nUser-Agent: curl\/8.5.0\n---0a1b2c3d-F--\nHTTP\/1.1 403 Forbidden\n---0a1b2c3d-H--\nMessage: Warning. Pattern match \"(?i:(?:union\\\\s+select))\" at ARGS:id. [file \"\/etc\/nginx\/modsec\/owasp-crs\/rules\/REQUEST-942-APPLICATION-ATTACK-SQLI.conf\"] [line \"542\"] [id \"942100\"] [rev \"\"] [msg \"SQL Injection Attack Detected via libinjection\"] [data \"Matched Data: union select found within ARGS:id\"] [severity \"CRITICAL\"] [ver \"OWASP_CRS\/4.0.0\"] [tag \"application-multi\"] [tag \"language-multi\"] [tag \"platform-multi\"] [tag \"attack-sqli\"]\nMessage: Access denied with code 403 (phase 2). Inbound Anomaly Score Exceeded (Total Score: 5) [file \"\/etc\/nginx\/modsec\/owasp-crs\/rules\/REQUEST-949-BLOCKING-EVALUATION.conf\"] [line \"120\"] [id \"949110\"]\n---0a1b2c3d-Z--<\/code><\/pre>\n
In production web applications, legitimate administrative updates (such as saving blog posts containing code snippets or raw HTML in WordPress) can trigger false positives against SQLi or XSS rules. Rather than disabling the entire rule globally, create surgical variable exclusions inside \/etc\/nginx\/modsec\/rules\/before-crs\/01-wordpress-exclusions.conf<\/code>:<\/p>\n
# Exclude specific rule from inspecting blog post body on admin endpoints\nSecRule REQUEST_URI \"@beginsWith \/wp-admin\/post.php\" \\\n    \"id:100001,phase:1,pass,nolog,ctl:ruleRemoveTargetById=941100;ARGS:content\"\n\n# Exclude REST API blocks for authenticated token headers\nSecRule REQUEST_URI \"@beginsWith \/wp-json\/wp\/v2\/posts\" \\\n    \"id:100002,phase:1,pass,nolog,ctl:ruleRemoveTargetById=942100;ARGS:content\"<\/code><\/pre>\n
\n
SysAdmin Tip:<\/strong> When onboarding new production microservices or upgrading OWASP Core Rule Sets, always run the firewall in SecRuleEngine DetectionOnly<\/code> mode for 72 to 96 hours. This logs prospective blocks to the audit log without interrupting legitimate user requests, allowing engineers to audit telemetry and tune exclusion rules before enabling full blocking mode (SecRuleEngine On<\/code>).<\/p>\n<\/blockquote>\n
Frequently Asked Questions<\/h2>\n
\nDoes running ModSecurity with Nginx introduce severe latency?<\/summary>\n
When properly tuned, ModSecurity v3 introduces between 1.2ms and 2.8ms of latency per request. Latency degradation only occurs if administrators enable SecResponseBodyAccess On<\/code> (forcing Nginx to buffer full output responses) or neglect to enable PCRE JIT compilation, which hardware-accelerates regular expression evaluation across incoming HTTP packets.<\/p>\n<\/details>\n
\nWhat is the primary architectural difference between ModSecurity v2 and libmodsecurity v3?<\/summary>\n
ModSecurity v2 was built as a monolithic Apache module tied to the Apache Portable Runtime (APR). Running v2 on Nginx required an emulation layer that blocked Nginx\u2019s event loop. Libmodsecurity v3 is a standalone C++ library that decouples parsing logic from web server internals, interfacing with Nginx asynchronously through the official ModSecurity-nginx<\/code> connector.<\/p>\n<\/details>\n
\nHow do I resolve false positives triggered by CMS editors or REST API payloads?<\/summary>\n
Never disable rule sets globally. Instead, inspect \/var\/log\/nginx\/modsec\/modsec_audit.log<\/code> to identify the triggered Rule ID and argument name. Create a targeted exclusion rule using ctl:ruleRemoveTargetById<\/code> scoped exclusively to the affected administrative URL path (e.g., \/wp-admin\/post.php<\/code>) before the OWASP CRS rules are processed.<\/p>\n<\/details>\n
\nCan ModSecurity dynamically drop repeat offender IPs at the Linux kernel firewall?<\/summary>\n
While ModSecurity operates at Layer 7 and returns HTTP 403 Forbidden responses, you can integrate its audit log with Fail2ban, CrowdSec, or an eBPF\/XDP pipeline. By matching ModSecurity 403 events in the audit log, Fail2ban can dynamically insert kernel iptables<\/code> or nftables<\/code> drop rules, discarding malicious packets at the network interface before they reach Nginx.<\/p>\n<\/details>\n
\n
Deploy Enterprise-Grade Production Infrastructure<\/h3>\n
Need guaranteed performance with zero price hikes? Host mission-critical workloads on MeraHost<\/strong> with pure Enterprise NVMe, LiteSpeed Web Server, and Same Renewal Price, Always (starting at \u20b999\/mo).<\/p>\n
\n
Explore MeraHost NVMe Cloud →<\/a><\/div>\n
Deploy Free Staging on CpanelFree<\/a><\/div>\n<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
Master enterprise Nginx ModSecurity setup using libmodsecurity3 and OWASP CRS v4. Discover production configs, performance tuning, and audit logging.<\/p>\n","protected":false},"author":1,"featured_media":4976,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[64],"tags":[57,69,177,87,101],"class_list":["post-4977","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-security","tag-almalinux","tag-cyber-security","tag-databases-performance","tag-devops","tag-sysadmin"],"_links":{"self":[{"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/posts\/4977","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/comments?post=4977"}],"version-history":[{"count":0,"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/posts\/4977\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/media\/4976"}],"wp:attachment":[{"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/media?parent=4977"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/categories?post=4977"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/tags?post=4977"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}