{"id":933,"date":"2026-08-20T23:23:41","date_gmt":"2026-08-20T23:23:41","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=933"},"modified":"2026-08-20T23:23:41","modified_gmt":"2026-08-20T23:23:41","slug":"systemd-service-hardening-vps","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/systemd-service-hardening-vps\/","title":{"rendered":"systemd Service Hardening on a VPS: ProtectSystem, PrivateTmp, and Dropping Capabilities"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\">Most VPS security guides stop at SSH keys and a firewall. The service layer is where attackers actually get in once they find a vulnerable process, and systemd gives you a set of sandboxing options that can contain a compromise before it becomes root access. This article covers the three highest-impact hardening directives \u2014 <code>ProtectSystem<\/code>, <code>PrivateTmp<\/code>, and capability dropping \u2014 plus the supporting options worth enabling, with working unit-file examples for a typical web stack.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Why Harden Systemd Services on a VPS?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">A VPS is a single tenancy kernel, so there is no hypervisor boundary between your services the way there is between containers. If nginx or PHP-FPM gets exploited, the attacker inherits that service&#8217;s privileges. systemd&#8217;s sandboxing directives turn those privileges into a minimal, read-only, capability-limited surface. On a 1-2 vCPU VPS the overhead is effectively zero \u2014 these are kernel-level restrictions, not another agent consuming RAM. The trade-off is configuration effort and occasional breakage, which is why each option below includes a verification step. For a baseline of what a securely provisioned VPS should look like, <a href=\"https:\/\/virtualserversvps.com\/#features\">the security and compliance details on our main site<\/a> list the checks we apply before any server goes live.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">ProtectSystem: Make the Filesystem Read-Only<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\"><code>ProtectSystem=<\/code> remounts parts of the filesystem read-only for the service. The levels are:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><code>ProtectSystem=yes<\/code> \u2014 makes <code>\/usr<\/code>, <code>\/boot<\/code>, and <code>\/etc<\/code> read-only.<\/li>\n<li><code>ProtectSystem=full<\/code> \u2014 adds <code>\/usr<\/code>, <code>\/boot<\/code>, <code>\/etc<\/code>, <code>\/lib<\/code>, <code>\/bin<\/code>, <code>\/sbin<\/code> and the whole root filesystem, keeping only <code>\/dev<\/code>, <code>\/proc<\/code>, <code>\/sys<\/code> and <code>\/home<\/code> writable.<\/li>\n<li><code>ProtectSystem=strict<\/code> \u2014 makes the entire filesystem hierarchy read-only except for explicitly whitelisted paths via <code>ReadWritePaths=<\/code>.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">For a web service, <code>strict<\/code> with an explicit writable list is the right target. A PHP-FPM pool that only needs to write to its session directory and log socket looks like this:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># \/etc\/systemd\/system\/php8.3-fpm.service.d\/hardening.conf\n[Service]\nProtectSystem=strict\nReadWritePaths=\/var\/lib\/php\/sessions \/run\/php\nProtectHome=true\nProtectKernelTunables=true\nProtectKernelModules=true\nProtectControlGroups=true<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Reload and verify that the service still writes where it needs to, then confirm the restriction is active:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>systemctl daemon-reload\nsystemctl restart php8.3-fpm\nsystemctl show php8.3-fpm -p ProtectSystem -p ReadWritePaths\n# expected: ProtectSystem=strict<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">The most common breakage with <code>strict<\/code> is an application that writes to an unexpected path \u2014 a cache directory, a temp file, or its own <code>chdir<\/code> directory. The fix is always to add that path to <code>ReadWritePaths=<\/code>, never to relax the whole setting. If an attacker later exploits the process, they can only write inside those explicitly listed directories, and they cannot modify binaries, libraries, or system configuration.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">PrivateTmp: Isolate \/tmp and \/var\/tmp<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Shared <code>\/tmp<\/code> is a classic cross-service attack surface: a compromised process can plant a symlink or a malicious file that another service with more privileges later executes. <code>PrivateTmp=true<\/code> gives the service its own private <code>\/tmp<\/code> and <code>\/var\/tmp<\/code> namespace, mounted via <code>PrivateDevices<\/code>-style file system namespaces. The service sees only its own temporary directory; nothing it writes there is visible to other services or to unprivileged local users.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>[Service]\nPrivateTmp=true\nPrivateDevices=true\nNoNewPrivileges=true<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><code>PrivateDevices=true<\/code> pairs well here: it gives the service a minimal <code>\/dev<\/code> with only <code>null<\/code>, <code>zero<\/code>, <code>random<\/code>, and <code>urandom<\/code>, blocking access to raw disks and hardware. <code>NoNewPrivileges=true<\/code> prevents the process and its children from gaining new privileges via setuid binaries \u2014 a cheap, universally safe addition. Note that <code>PrivateTmp<\/code> is per-service; if two services need to share a temp file, use an explicit directory under <code>ReadWritePaths=<\/code> instead of relying on <code>\/tmp<\/code>. The performance impact on a VPS is negligible because these are namespace and mount operations performed once at service start.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Drop Capabilities with CapabilityBoundingSet<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Capabilities are the granular privileges Linux grants to processes that would otherwise need full root. A service started as root holds a bounding set of all capabilities it may ever gain; you should trim that set to what the service actually uses. For nginx, which needs to bind to port 80\/443, read config, and manage its worker processes, a hardened set looks like:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># \/etc\/systemd\/system\/nginx.service.d\/hardening.conf\n[Service]\nCapabilityBoundingSet=CAP_NET_BIND_SERVICE CAP_NET_RAW CAP_DAC_OVERRIDE CAP_SETUID CAP_SETGID CAP_CHOWN CAP_FOWNER\nAmbientCapabilities=CAP_NET_BIND_SERVICE\nNoNewPrivileges=true<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">What this does in practice:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><code>CAP_NET_BIND_SERVICE<\/code> \u2014 bind to privileged ports below 1024.<\/li>\n<li><code>CAP_NET_RAW<\/code> \u2014 needed if nginx uses the <code>realip<\/code> module&#8217;s raw socket checks; drop it if your setup does not require it.<\/li>\n<li><code>CAP_DAC_OVERRIDE<\/code> \u2014 read files the service user may not own; often droppable if you fix file ownership instead.<\/li>\n<li><code>CAP_SETUID<\/code>\/<code>CAP_SETGID<\/code> \u2014 allow the master process to drop privileges for workers.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Verify the effective set after restart:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>systemctl restart nginx\nsystemctl show nginx -p CapabilityBoundingSet\n# or from the process itself:\ngrep Cap \/proc\/$(pgrep -o nginx)\/status\ncapsh --decode=$(grep CapEff \/proc\/$(pgrep -o nginx)\/status | awk '{print $2}')<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">The goal is not a minimal theoretical set; it is removing the capabilities that a real exploit would use to escalate \u2014 <code>CAP_SYS_ADMIN<\/code>, <code>CAP_SYS_PTRACE<\/code>, <code>CAP_SYS_MODULE<\/code>, and <code>CAP_DAC_READ_SEARCH<\/code> should never appear in a web service&#8217;s bounding set. If the service fails to start after tightening, check <code>journalctl -u &lt;service&gt; -n 50<\/code> for permission errors and re-add only the specific capability the error names. A full walkthrough of applying these units across nginx, PHP-FPM, and a database is beyond this article, but <a href=\"https:\/\/virtualserversvps.com\/#providers\">the provider comparison table on our main site<\/a> can help you pick a VPS plan with enough headroom that these hardening layers never cost you performance.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Supporting Options Worth Enabling<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">These four directives cost almost nothing and close common holes:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><code>RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX<\/code> \u2014 blocks raw packet sockets and netlink, stopping a class of network-based privilege escalation.<\/li>\n<li><code>MemoryDenyWriteExecute=true<\/code> \u2014 prevents <code>mmap<\/code> with both write and execute permissions; breaks JIT runtimes like V8, so test carefully before enabling on Node.js services.<\/li>\n<li><code>RestrictRealtime=true<\/code> \u2014 blocks real-time scheduling policies that could be abused for CPU starvation.<\/li>\n<li><code>SystemCallFilter=@system-service<\/code> \u2014 an allowlist of syscalls; start with this and add exceptions only when the application demonstrably needs them.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">You can audit all of a service&#8217;s effective restrictions in one command:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>systemd-analyze security nginx\n# produces a 0-10 exposure score per service and lists which directives are unset<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><code>systemd-analyze security<\/code> is the fastest way to find gaps: it prints every hardening option and flags the ones you left at their insecure defaults. Run it on every service exposed to the network, and treat anything scoring above 5 as a candidate for the directives above.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Testing Your Hardened Configuration<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Before declaring victory, prove the sandbox works. As the service user (or from a shell that drops to it), attempt the actions the directives should block:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># should fail under ProtectSystem=strict\nsudo -u www-data touch \/etc\/test-write\n# should fail under PrivateTmp \u2014 the file is invisible to other users\nls \/tmp\/php-session-test\n# should fail under the trimmed capability set\ncapsh --drop=all -- -c 'setcap cap_sys_admin+ep \/bin\/true'<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Each failed attempt confirms the boundary is real, not just declared. Then re-run your normal health checks \u2014 site loads, sessions persist, logs rotate \u2014 to confirm the service still functions. Hardening that breaks the application is a denial of service; the verification loop is what keeps the two in balance. If you are moving a hardened workload between providers, <a href=\"https:\/\/virtualserversvps.com\/#faq\">our FAQ covers what to re-check after migration<\/a>, since kernel versions differ and a directive that parses on Ubuntu 24.04 may need adjustment elsewhere.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Summary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><code>ProtectSystem=strict<\/code> with explicit <code>ReadWritePaths=<\/code> makes most of the filesystem read-only for the service.<\/li>\n<li><code>PrivateTmp=true<\/code> isolates temporary files per service and kills the shared-<code>\/tmp<\/code> attack surface.<\/li>\n<li><code>CapabilityBoundingSet=<\/code> trims what a compromised process can do, and <code>NoNewPrivileges=true<\/code> prevents escalation via setuid.<\/li>\n<li>Audit with <code>systemd-analyze security<\/code> and verify each restriction with a real failed attempt.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">These three directives \u2014 <code>ProtectSystem<\/code>, <code>PrivateTmp<\/code>, and capability dropping \u2014 give you most of the isolation benefit of containers with none of the orchestration overhead, directly on the host kernel of your VPS. Apply them to every network-facing service, verify each one, and the blast radius of any single compromise shrinks dramatically.<\/p>\n\n","protected":false},"excerpt":{"rendered":"<p>Most VPS security guides stop at SSH keys and a firewall. The service layer is where attackers actually get in once they find a vulnerable process, and systemd gives you&#8230;<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":0,"footnotes":""},"categories":[4],"tags":[],"class_list":["post-933","post","type-post","status-publish","format-standard","hentry","category-security-compliance"],"yoast_head":"<!-- This site is optimized with the Yoast SEO Premium plugin v26.1 (Yoast SEO v26.1) - https:\/\/yoast.com\/wordpress\/plugins\/seo\/ -->\n<title>systemd Service Hardening on a VPS: ProtectSystem, PrivateTmp, and Dropping Capabilities - Virtual Servers VPS Blog<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/virtualserversvps.com\/blog\/systemd-service-hardening-vps\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"systemd Service Hardening on a VPS: ProtectSystem, PrivateTmp, and Dropping Capabilities\" \/>\n<meta property=\"og:description\" content=\"systemd Service Hardening on a VPS: ProtectSystem, PrivateTmp, and Dropping Capabilities\" \/>\n<meta property=\"og:url\" content=\"https:\/\/virtualserversvps.com\/blog\/systemd-service-hardening-vps\/\" \/>\n<meta property=\"og:site_name\" content=\"Virtual Servers VPS Blog\" \/>\n<meta property=\"article:published_time\" content=\"2026-08-20T23:23:41+00:00\" \/>\n<meta name=\"author\" content=\"Virtual-Servers-Vps-Editor\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Virtual-Servers-Vps-Editor\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"7 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\/\/virtualserversvps.com\/blog\/systemd-service-hardening-vps\/\",\"url\":\"https:\/\/virtualserversvps.com\/blog\/systemd-service-hardening-vps\/\",\"name\":\"systemd Service Hardening on a VPS: ProtectSystem, PrivateTmp, and Dropping Capabilities - Virtual Servers VPS Blog\",\"isPartOf\":{\"@id\":\"https:\/\/virtualserversvps.com\/blog\/#website\"},\"datePublished\":\"2026-08-20T23:23:41+00:00\",\"author\":{\"@id\":\"https:\/\/virtualserversvps.com\/blog\/#\/schema\/person\/82a299a8284a66ff49f97c74684724a0\"},\"breadcrumb\":{\"@id\":\"https:\/\/virtualserversvps.com\/blog\/systemd-service-hardening-vps\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/virtualserversvps.com\/blog\/systemd-service-hardening-vps\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/virtualserversvps.com\/blog\/systemd-service-hardening-vps\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/virtualserversvps.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"systemd Service Hardening on a VPS: ProtectSystem, PrivateTmp, and Dropping Capabilities\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/virtualserversvps.com\/blog\/#website\",\"url\":\"https:\/\/virtualserversvps.com\/blog\/\",\"name\":\"Virtual Servers VPS Blog\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/virtualserversvps.com\/blog\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\/\/virtualserversvps.com\/blog\/#\/schema\/person\/82a299a8284a66ff49f97c74684724a0\",\"name\":\"Virtual-Servers-Vps-Editor\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/virtualserversvps.com\/blog\/#\/schema\/person\/image\/\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/d820b15f1cd028e97610d9adf536df7be5cb6423869967037d468d5355fa003f?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/d820b15f1cd028e97610d9adf536df7be5cb6423869967037d468d5355fa003f?s=96&d=mm&r=g\",\"caption\":\"Virtual-Servers-Vps-Editor\"},\"sameAs\":[\"https:\/\/virtualserversvps.com\/blog\"],\"url\":\"https:\/\/virtualserversvps.com\/blog\/author\/virtualserversvps\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"systemd Service Hardening on a VPS: ProtectSystem, PrivateTmp, and Dropping Capabilities - Virtual Servers VPS Blog","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/virtualserversvps.com\/blog\/systemd-service-hardening-vps\/","og_locale":"en_US","og_type":"article","og_title":"systemd Service Hardening on a VPS: ProtectSystem, PrivateTmp, and Dropping Capabilities","og_description":"systemd Service Hardening on a VPS: ProtectSystem, PrivateTmp, and Dropping Capabilities","og_url":"https:\/\/virtualserversvps.com\/blog\/systemd-service-hardening-vps\/","og_site_name":"Virtual Servers VPS Blog","article_published_time":"2026-08-20T23:23:41+00:00","author":"Virtual-Servers-Vps-Editor","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Virtual-Servers-Vps-Editor","Est. reading time":"7 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/virtualserversvps.com\/blog\/systemd-service-hardening-vps\/","url":"https:\/\/virtualserversvps.com\/blog\/systemd-service-hardening-vps\/","name":"systemd Service Hardening on a VPS: ProtectSystem, PrivateTmp, and Dropping Capabilities - Virtual Servers VPS Blog","isPartOf":{"@id":"https:\/\/virtualserversvps.com\/blog\/#website"},"datePublished":"2026-08-20T23:23:41+00:00","author":{"@id":"https:\/\/virtualserversvps.com\/blog\/#\/schema\/person\/82a299a8284a66ff49f97c74684724a0"},"breadcrumb":{"@id":"https:\/\/virtualserversvps.com\/blog\/systemd-service-hardening-vps\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/virtualserversvps.com\/blog\/systemd-service-hardening-vps\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/virtualserversvps.com\/blog\/systemd-service-hardening-vps\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/virtualserversvps.com\/blog\/"},{"@type":"ListItem","position":2,"name":"systemd Service Hardening on a VPS: ProtectSystem, PrivateTmp, and Dropping Capabilities"}]},{"@type":"WebSite","@id":"https:\/\/virtualserversvps.com\/blog\/#website","url":"https:\/\/virtualserversvps.com\/blog\/","name":"Virtual Servers VPS Blog","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/virtualserversvps.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/virtualserversvps.com\/blog\/#\/schema\/person\/82a299a8284a66ff49f97c74684724a0","name":"Virtual-Servers-Vps-Editor","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/virtualserversvps.com\/blog\/#\/schema\/person\/image\/","url":"https:\/\/secure.gravatar.com\/avatar\/d820b15f1cd028e97610d9adf536df7be5cb6423869967037d468d5355fa003f?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/d820b15f1cd028e97610d9adf536df7be5cb6423869967037d468d5355fa003f?s=96&d=mm&r=g","caption":"Virtual-Servers-Vps-Editor"},"sameAs":["https:\/\/virtualserversvps.com\/blog"],"url":"https:\/\/virtualserversvps.com\/blog\/author\/virtualserversvps\/"}]}},"_links":{"self":[{"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/posts\/933","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/comments?post=933"}],"version-history":[{"count":1,"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/posts\/933\/revisions"}],"predecessor-version":[{"id":935,"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/posts\/933\/revisions\/935"}],"wp:attachment":[{"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/media?parent=933"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/categories?post=933"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/tags?post=933"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}