# Hardening Reference Detailed guidance on every security control available in Steel Security. # File & Execution Protection File & Execution Protection # Uploads PHP Execution Protection ## What This Does This protection prevents PHP files from executing within the WordPress uploads directory. It ensures that any uploaded files cannot be used to run code on your server. --- ## Why It Matters The uploads directory is writable by WordPress. If an attacker is able to upload a malicious PHP file, they may be able to execute it and gain control of your site. Blocking PHP execution in this directory removes a common attack vector. --- ## When to Apply It This protection is recommended for most WordPress sites. Apply it when: - your uploads directory is used for media files only - you do not intentionally run PHP from uploads - you want to reduce risk from file upload vulnerabilities --- ## When Not to Apply It Do not apply this protection if: - your site intentionally executes PHP from the uploads directory - a plugin or custom functionality depends on this behavior If unsure, apply cautiously and test your site. --- ## How Steel Security Applies This Steel Security applies this protection by modifying server behavior. Depending on your environment, this may include: - Apache (.htaccess) rules - Nginx configuration guidance - IIS web.config rules These rules prevent PHP files from executing within the uploads directory. --- ## What to Expect After Applying After applying this protection: - PHP files in uploads will no longer execute - media uploads will continue to function normally - your site becomes more resistant to file upload exploits --- ## How to Verify To verify the protection: 1. Attempt to access a PHP file within the uploads directory 2. Confirm that execution is blocked You may see: - a denied access response - the file downloaded instead of executed - an error from the server --- ## How to Revert (Rollback) To revert this protection: 1. Navigate to the hardening section in Steel Security 2. Disable the control 3. Confirm the change 4. Test your site functionality The uploads directory will return to its previous behavior. --- ## Common Issues ### File Downloads Instead of Executing This is expected behavior. Execution is being blocked as intended. --- ### Plugin Stops Working Some plugins may rely on executing PHP in uploads. If this occurs: - revert the change - investigate plugin behavior - consider alternative configurations --- ## Related - [Safe Rollback Practices](https://docs.steelsecurity.com/books/plugin-guide/page/safe-rollback-practices) - [Working with Scan Findings](https://docs.steelsecurity.com/books/plugin-guide/page/working-with-scan-findings) # Block Direct PHP Access ## What This Does This protection prevents direct access to PHP files that are not intended to be accessed via a browser. It ensures that internal scripts cannot be executed outside of normal WordPress workflows. --- ## Why It Matters Many PHP files within a WordPress site are meant to be included internally, not accessed directly. If these files are accessible, attackers may: - execute scripts in unintended ways - bypass application logic - probe for vulnerabilities Blocking direct access reduces this risk. --- ## When to Apply It This protection is recommended for most production websites. Apply it when: - your site contains custom or plugin PHP files - you want to prevent unauthorized script execution - you are reducing attack surface --- ## When to Be Cautious Be cautious when: - certain PHP files are intentionally accessed directly - integrations rely on direct script access - custom endpoints are implemented outside WordPress routing Test thoroughly after applying. --- ## How Steel Security Applies This Steel Security restricts direct access to PHP files using server-level rules. This may include: - blocking direct requests to specific PHP files - allowing execution only through WordPress entry points - applying rules to common sensitive locations The exact implementation depends on your server environment. --- ## What to Expect After Applying After applying this protection: - direct access to restricted PHP files will be blocked - unauthorized execution attempts will fail - normal site functionality should remain unchanged --- ## How to Verify To verify the protection: 1. Attempt to access a PHP file directly via URL 2. Confirm that access is denied (e.g., 403 Forbidden) Ensure: - legitimate site functionality still works - restricted files are not accessible directly --- ## How to Revert (Rollback) To revert this protection: 1. Navigate to the hardening section in Steel Security 2. Disable or adjust the control 3. Confirm the change 4. re-test affected functionality --- ## Common Issues ### Legitimate Script Access Is Blocked This may occur if: - a file is intended to be accessed directly - custom logic depends on direct execution To resolve: - adjust the rule - allow specific files if necessary - revert the change if required --- ### No Change Observed - verify rules are applied correctly - check server configuration - confirm no conflicting rules exist --- ## Best Practices - avoid direct access to internal PHP files - route execution through WordPress where possible - test all custom functionality after applying - combine with other execution restrictions --- ## Related - [Prevent Execution in Sensitive Directories](https://docs.steelwp.com/books/hardening-reference/page/prevent-execution-in-sensitive-directories) - [Restrict Sensitive Endpoints](https://docs.steelwp.com/books/hardening-reference/page/restrict-sensitive-endpoints) - [Safe Rollback Practices](https://docs.steelsecurity.com/books/plugin-guide/page/safe-rollback-practices) # Prevent Execution in Sensitive Directories ## What This Does This protection prevents PHP execution within directories that should only store data, not executable code. It helps ensure that uploaded or stored files cannot be used to run malicious scripts. --- ## Why It Matters Certain directories are intended for storage, such as: - `/wp-content/uploads/` - cache directories - temporary or backup locations If PHP execution is allowed in these locations, attackers may: - upload malicious scripts - execute code through vulnerable upload points - gain unauthorized access or control Blocking execution in these directories significantly reduces this risk. --- ## When to Apply It This protection is strongly recommended for all production websites. Apply it when: - your site allows file uploads - you use media libraries or file storage - you want to prevent execution of uploaded content --- ## When to Be Cautious Be cautious when: - legitimate PHP execution is required in these directories (rare) - custom applications rely on dynamic execution in storage locations Always test after applying. --- ## How Steel Security Applies This Steel Security applies server-level rules to prevent PHP execution in sensitive directories. This may include: - disabling PHP processing in upload directories - restricting execution in storage or cache paths - applying directory-specific rules The exact implementation depends on your server environment. --- ## What to Expect After Applying After applying this protection: - PHP files in sensitive directories will not execute - uploaded scripts will be treated as files, not code - your site will be more resistant to upload-based attacks --- ## How to Verify To verify the protection: 1. Upload or place a test PHP file in a protected directory 2. attempt to access it via browser 3. confirm that execution is blocked Expected results include: - file download instead of execution - or access denied (e.g., 403 Forbidden) --- ## How to Revert (Rollback) To revert this protection: 1. Navigate to the hardening section in Steel Security 2. disable or adjust the control 3. confirm the change 4. re-test directory behavior --- ## Common Issues ### Uploaded Files Do Not Behave as Expected - verify file types and handling - confirm no legitimate PHP execution is required --- ### No Visible Change This is expected if: - no executable files are present - the environment was already secure --- ### Rule Not Applied - verify server supports directory-level restrictions - check for conflicting configuration - confirm rules are active --- ## Best Practices - never allow PHP execution in upload directories - treat storage locations as non-executable - regularly review file upload behavior - combine with other file protection controls --- ## Related - [Block Direct PHP Access](https://docs.steelwp.com/books/hardening-reference/page/block-direct-php-access) - [Protect Configuration Files](https://docs.steelwp.com/books/hardening-reference/page/protect-configuration-files) - [Protect Backup Files](https://docs.steelwp.com/books/hardening-reference/page/protect-backup-files) - [Safe Rollback Practices](https://docs.steelsecurity.com/books/plugin-guide/page/safe-rollback-practices) # Directory & File Exposure Directory & File Exposure # Disable Directory Listing ## What This Does This protection disables directory listing on your web server. It prevents visitors from viewing the contents of directories that do not have an index file. --- ## Why It Matters If directory listing is enabled, anyone can browse files in certain folders on your site. This can expose: - uploaded files - backup files - configuration artifacts - internal file structures Even if the files themselves are not sensitive, this information can help attackers understand your system. --- ## When to Apply It This protection is recommended for all WordPress sites. Apply it when: - directory listing is enabled on your server - you want to prevent public browsing of directories - your site does not require directory visibility --- ## When Not to Apply It Do not apply this protection if: - your site intentionally relies on directory listing - you are hosting files meant to be publicly browsable This is uncommon for most WordPress environments. --- ## How Steel Security Applies This Steel Security disables directory listing at the server level. Depending on your environment, this may include: - Apache: disabling indexes via `.htaccess` - Nginx: configuration guidance - IIS: web.config rules These changes prevent directory contents from being displayed. --- ## What to Expect After Applying After applying this protection: - directories without an index file will no longer display contents - users may see a 403 Forbidden or similar message - your file structure is no longer publicly visible --- ## How to Verify To verify the protection: 1. Navigate to a directory on your site without an index file 2. Confirm that the contents are not displayed Expected results include: - a 403 Forbidden response - a blank or denied page --- ## How to Revert (Rollback) To revert this protection: 1. Navigate to the hardening section in Steel Security 2. Disable the control 3. Confirm the change 4. Re-test the directory Directory listing behavior will return to its previous state. --- ## Common Issues ### Directory Shows an Error Page This is expected. The server is blocking access to the directory listing. --- ### Files Are No Longer Visible If you relied on directory browsing: - revert the change - consider adding an index file instead --- ## Related - [Uploads PHP Execution Protection](https://docs.steelwp.com/books/hardening-reference/page/uploads-php-execution-protection) - [Safe Rollback Practices](https://docs.steelsecurity.com/books/plugin-guide/page/safe-rollback-practices) # Protect Backup Files ## What This Does This protection prevents backup and archive files from being accessed directly via the web. It restricts access to files that may contain full or partial copies of your site or database. --- ## Why It Matters Backup files often contain: - full database dumps - site files and uploads - configuration data - sensitive credentials If exposed, an attacker can download these files and gain complete insight into your site. This can lead to: - account compromise - data exposure - full site takeover --- ## When to Apply It This protection is strongly recommended for all sites. Apply it when: - backup files exist on your server - your site generates or stores archives - you want to prevent accidental exposure --- ## When Not to Apply It In most cases, this protection should always be applied. Only avoid applying if: - backup files are intentionally public (rare and discouraged) - you are serving downloadable archives intentionally Even in these cases, alternative secure delivery methods are recommended. --- ## How Steel Security Applies This Steel Security blocks access to common backup and archive file types. This may include: - `.zip`, `.tar`, `.gz` archives - `.sql` database dumps - other backup-related file formats Protection is applied using server-level rules such as: - Apache `.htaccess` restrictions - Nginx configuration guidance - IIS web.config rules --- ## What to Expect After Applying After applying this protection: - backup files will not be accessible via browser - access attempts will return an error (e.g., 403 Forbidden) - files remain on the server but are protected --- ## How to Verify To verify the protection: 1. Attempt to access a known backup file via your browser 2. Confirm that access is denied You should not be able to download or view the file. --- ## How to Revert (Rollback) To revert this protection: 1. Navigate to the hardening section in Steel Security 2. Disable the control 3. Confirm the change 4. Re-test file access Access will return to its previous behavior. --- ## Common Issues ### Backup Files Are No Longer Accessible This is expected. The protection is blocking direct access. If you need access: - use FTP or SSH - move files outside the web root - temporarily revert the protection if necessary --- ### File Download Is Blocked This indicates the protection is working correctly. --- ### Protection Does Not Apply - verify server supports the rule set - check for conflicting directives - confirm file extensions match expected patterns --- ## Related - [Protect Configuration Files](https://docs.steelwp.com/books/hardening-reference/page/protect-configuration-files) - [Disable Directory Listing](https://docs.steelwp.com/books/hardening-reference/page/disable-directory-listing) - [Safe Rollback Practices](https://docs.steelsecurity.com/books/plugin-guide/page/safe-rollback-practices) # Protect Configuration Files ## What This Does This protection restricts access to sensitive configuration files within your site. It prevents these files from being accessed directly via the web. --- ## Why It Matters Configuration files may contain sensitive information such as: - database credentials - API keys - environment settings - internal configuration details If exposed, these files can allow attackers to: - access your database - compromise your site - escalate access to your server --- ## When to Apply It This protection is recommended for all WordPress sites. Apply it when: - configuration files exist within your web-accessible directories - you want to prevent direct access to sensitive data - your server does not already restrict access --- ## When Not to Apply It In most cases, this protection should always be applied. Only avoid applying if: - your hosting environment already enforces strict access controls - custom configurations require public access (rare and discouraged) --- ## How Steel Security Applies This Steel Security protects configuration files using server-level rules. Depending on your environment, this may include: - Apache `.htaccess` restrictions - Nginx configuration guidance - IIS web.config rules These rules block direct web access to known sensitive file types. --- ## What to Expect After Applying After applying this protection: - configuration files will not be accessible via browser - attempts to access them will return an error (e.g., 403 Forbidden) - your site functionality will remain unchanged --- ## How to Verify To verify the protection: 1. Attempt to access a known configuration file via your browser 2. Confirm that access is denied You should not be able to view file contents. --- ## How to Revert (Rollback) To revert this protection: 1. Navigate to the hardening section in Steel Security 2. Disable the control 3. Confirm the change 4. Re-test file access Access will return to its previous behavior. --- ## Common Issues ### File Access Is Blocked This is expected. The protection is preventing exposure of sensitive data. --- ### Legitimate Access Is Affected If a system requires access: - review how the file is being accessed - consider alternative secure methods - revert only if absolutely necessary --- ### Protection Does Not Work - verify server configuration supports the rules - check for conflicting server directives - ensure file paths match expected patterns --- ## Related - [Protect Backup Files](https://docs.steelwp.com/books/hardening-reference/page/protect-backup-files) - [Disable Directory Listing](https://docs.steelwp.com/books/hardening-reference/page/disable-directory-listing) - [Safe Rollback Practices](https://docs.steelsecurity.com/books/plugin-guide/page/safe-rollback-practices) # WordPress Configuration Hardening WordPress Configuration Hardening # Disable Debug Mode ## What This Does This protection ensures that WordPress debug mode is disabled in production environments. It prevents error messages and diagnostic information from being displayed publicly. --- ## Why It Matters When debug mode is enabled, WordPress may display: - PHP errors and warnings - file paths and system structure - plugin and theme information - database query details This information can expose sensitive details about your site and make it easier for attackers to identify vulnerabilities. --- ## When to Apply It This protection is recommended for all production websites. Apply it when: - your site is publicly accessible - development is complete - you want to prevent information leakage --- ## When Not to Apply It You may choose not to apply this protection if: - you are actively developing or debugging your site - you require visible error output for troubleshooting In these cases, debug mode should only be enabled temporarily and never on a live site. --- ## How Steel Security Applies This Steel Security ensures debug settings are configured securely. This typically involves: - disabling `WP_DEBUG` - preventing error display in the browser - ensuring errors are not publicly exposed Changes are applied directly to your WordPress configuration. --- ## What to Expect After Applying After applying this protection: - errors will no longer be displayed publicly - your site will appear cleaner and more stable to users - sensitive debugging information will be hidden This does not prevent errors from occurring — it only prevents exposure. --- ## How to Verify To verify the protection: 1. Trigger or observe an error on your site (if applicable) 2. Confirm that error details are not displayed publicly You should not see: - PHP warnings - file paths - stack traces --- ## How to Revert (Rollback) To revert this protection: 1. Navigate to the hardening section in Steel Security 2. Disable the control 3. Confirm the change 4. Verify that debug output is restored (if needed) Only enable debug mode temporarily and with caution. --- ## Common Issues ### Errors Are No Longer Visible This is expected. Debug output is being hidden for security. If needed: - enable logging instead of display - review server logs for diagnostics --- ### Changes Do Not Take Effect - confirm configuration was updated correctly - check for conflicting settings in `wp-config.php` - ensure hosting environment is not overriding values --- ## Related - [Uploads PHP Execution Protection](https://docs.steelwp.com/books/hardening-reference/page/uploads-php-execution-protection) - [Disable Directory Listing](https://docs.steelwp.com/books/hardening-reference/page/disable-directory-listing) - [Safe Rollback Practices](https://docs.steelsecurity.com/books/plugin-guide/page/safe-rollback-practices) # Disable File Editing in Admin ## What This Does This protection disables the built-in WordPress file editor within the admin dashboard. It prevents users from editing theme and plugin files directly through the WordPress interface. --- ## Why It Matters By default, WordPress allows administrators to edit PHP files directly from the dashboard. If an attacker gains admin access, they can: - inject malicious code - modify plugin or theme files - create persistent backdoors Disabling file editing removes an easy path for exploitation. --- ## When to Apply It This protection is recommended for most WordPress sites. Apply it when: - your site is in production - you manage code through FTP, SSH, or version control - you want to reduce risk from compromised admin accounts --- ## When Not to Apply It You may choose not to apply this protection if: - you rely on the built-in editor for quick changes - you do not have alternative access (FTP/SSH) - your workflow depends on in-dashboard editing If used, the editor should still be limited to trusted users only. --- ## How Steel Security Applies This Steel Security disables file editing by updating WordPress configuration. This typically involves setting: - `DISALLOW_FILE_EDIT` to true This removes access to the theme and plugin editors in the admin interface. --- ## What to Expect After Applying After applying this protection: - the Theme Editor and Plugin Editor will no longer be accessible - users will not be able to edit files from the dashboard - existing functionality of your site will remain unchanged --- ## How to Verify To verify the protection: 1. Log in to your WordPress admin 2. Navigate to Appearance → Theme File Editor 3. Navigate to Plugins → Plugin File Editor These options should no longer be available. --- ## How to Revert (Rollback) To revert this protection: 1. Navigate to the hardening section in Steel Security 2. Disable the control 3. Confirm the change 4. Refresh the admin interface The file editors will become available again. --- ## Common Issues ### Editor Is Missing This is expected. The file editing feature has been disabled for security. --- ### Unable to Make Quick Changes If you relied on the editor: - use FTP or SSH instead - revert the setting if necessary - consider updating your workflow --- ### Setting Does Not Take Effect - check for conflicting definitions in `wp-config.php` - ensure the configuration is not overridden by hosting --- ## Related - [Disable Debug Mode](https://docs.steelwp.com/books/hardening-reference/page/disable-debug-mode) - [Safe Rollback Practices](https://docs.steelsecurity.com/books/plugin-guide/page/safe-rollback-practices) # Restrict XML-RPC ## What This Does This protection restricts or disables access to the WordPress XML-RPC interface. It reduces exposure to certain types of automated attacks that target this endpoint. --- ## Why It Matters XML-RPC is a remote access feature that allows external systems to interact with your WordPress site. While useful in some cases, it is commonly targeted for: - brute force login attacks - pingback and amplification attacks - automated abuse of authentication endpoints If not needed, leaving XML-RPC enabled increases your attack surface. --- ## When to Apply It This protection is recommended for most WordPress sites. Apply it when: - you do not use XML-RPC functionality - your site does not rely on remote publishing tools - you want to reduce exposure to automated attacks --- ## When Not to Apply It Do not apply this protection if your site depends on XML-RPC. This may include: - certain mobile apps - remote publishing tools - integrations that rely on XML-RPC If unsure, apply cautiously and test functionality. --- ## How Steel Security Applies This Steel Security restricts access to the XML-RPC endpoint (`xmlrpc.php`). Depending on your environment, this may include: - blocking access at the server level - limiting allowed request types - restricting access to specific conditions This prevents unauthorized or unnecessary use of the interface. --- ## What to Expect After Applying After applying this protection: - XML-RPC requests will be blocked or restricted - automated attacks targeting the endpoint will be reduced - your site functionality will remain unchanged if XML-RPC is not in use --- ## How to Verify To verify the protection: 1. Attempt to access `/xmlrpc.php` in your browser 2. Confirm that access is denied or restricted Expected results include: - a 403 Forbidden response - a blocked or limited response --- ## How to Revert (Rollback) To revert this protection: 1. Navigate to the hardening section in Steel Security 2. Disable the control 3. Confirm the change 4. Re-test any integrations that rely on XML-RPC --- ## Common Issues ### Remote Publishing Stops Working This indicates XML-RPC was in use. If needed: - revert the change - confirm which tool requires XML-RPC - consider alternative APIs (e.g., REST API) --- ### Endpoint Still Accessible - verify server rules are applied correctly - check for caching or proxy interference - confirm no conflicting configuration exists --- ### Unexpected Behavior - test all integrations after applying - revert if functionality is impacted - apply more targeted restrictions if needed --- ## Related - [Disable File Editing in Admin](https://docs.steelwp.com/books/hardening-reference/page/disable-file-editing-in-admin) - [Protect Configuration Files](https://docs.steelwp.com/books/hardening-reference/page/protect-configuration-files) - [Safe Rollback Practices](https://docs.steelsecurity.com/books/plugin-guide/page/safe-rollback-practices) # HTTP & Browser Security HTTP & Browser Security # Security Headers Overview ## What This Covers This page provides an overview of HTTP security headers and how they help protect your website. Security headers are a set of instructions sent by your server to the browser to control how content is handled and secured. --- ## What Are Security Headers Security headers are HTTP response headers that define how browsers should behave when interacting with your site. They can: - prevent certain types of attacks - restrict how content is loaded - control how your site is embedded or accessed They are applied at the server level and affect all visitors. --- ## Why They Matter Security headers help protect against common web-based attacks, including: - cross-site scripting (XSS) - clickjacking - MIME-type sniffing - data leakage through referrers They add an additional layer of defense beyond your application code. --- ## How Steel Security Uses Security Headers Steel Security provides guidance and controls for applying security headers safely. Depending on your environment, this may involve: - Apache `.htaccess` rules - Nginx configuration guidance - IIS web.config rules Headers are applied at the server level to ensure consistent protection. --- ## Common Security Headers Steel Security supports or references several important headers, including: - Content Security Policy (CSP) - X-Frame-Options - X-Content-Type-Options - Referrer-Policy Each header serves a specific purpose and should be configured carefully. --- ## When to Apply Security Headers Security headers are recommended for most production websites. Apply them when: - your site is publicly accessible - you want to improve browser-level security - you are following modern security best practices --- ## When to Be Cautious Some headers, especially Content Security Policy (CSP), can affect how your site loads resources. Be cautious when: - your site loads external scripts or assets - you use third-party integrations - your configuration is complex Always test after applying changes. --- ## What to Expect After Applying After applying security headers: - browsers will enforce stricter security rules - some unsafe behaviors will be blocked - your site may require adjustments if dependencies are restricted Most basic headers will not impact functionality. --- ## How to Verify To verify security headers: 1. Open your browser developer tools 2. Navigate to the Network tab 3. Inspect a page request 4. Review the response headers You should see the applied security headers listed. --- ## How to Revert (Rollback) To revert security headers: 1. Navigate to the hardening section in Steel Security 2. Disable the relevant control 3. Confirm the change 4. Re-check headers in your browser --- ## Common Issues ### Site Content Breaks - often caused by overly strict policies (especially CSP) - review which resources are being blocked - adjust or revert the configuration --- ### Headers Not Appearing - verify server supports header rules - check for caching or CDN interference - confirm configuration was applied correctly --- ### Conflicting Headers - multiple configurations may overlap - ensure only one source is managing headers - review server and plugin interactions --- ## Related - [Content Security Policy (CSP)](https://docs.steelwp.com/books/hardening-reference/page/content-security-policy-csp) - [X-Frame-Options](https://docs.steelwp.com/books/hardening-reference/page/x-frame-options) - [X-Content-Type-Options](https://docs.steelwp.com/books/hardening-reference/page/x-content-type-options) - [Referrer-Policy](https://docs.steelwp.com/books/hardening-reference/page/referrer-policy) - [Safe Rollback Practices](https://docs.steelsecurity.com/books/plugin-guide/page/safe-rollback-practices) # Content Security Policy (CSP) ## What This Does Content Security Policy (CSP) defines which sources of content are allowed to load on your website. It helps prevent unauthorized scripts, styles, and other resources from executing in the browser. --- ## Why It Matters Modern websites load content from many sources, including: - scripts - stylesheets - images - fonts - external services Without restrictions, malicious content can be injected and executed. Content Security Policy (CSP) helps protect against: - cross-site scripting (XSS) attacks - malicious script injection - unauthorized third-party content --- ## When to Apply It CSP is recommended for sites that want stronger browser-level protection. Apply it when: - you understand your site's resource loading behavior - you are prepared to test and adjust policies - you want to reduce reliance on browser trust --- ## When to Be Cautious CSP can break site functionality if configured incorrectly. Be cautious when: - your site loads resources from multiple domains - you use third-party scripts (analytics, ads, CDNs) - your site relies on inline scripts or styles Always test thoroughly after applying. --- ## How Steel Security Supports This Steel Security does not currently provide full Content Security Policy (CSP) management. CSP is a complex and highly environment-specific control that typically requires manual configuration. Steel Security focuses on providing safe, broadly applicable protections first, while offering guidance for more advanced controls like CSP. Support for CSP may be expanded in future versions. --- ## How to Apply This Manually CSP is typically applied using HTTP response headers at the server level. Depending on your environment, this may involve: - Apache `.htaccess` configuration - Nginx server configuration - IIS web.config rules Because CSP must be tailored to your specific site, it should be implemented carefully and tested thoroughly. --- ## What to Expect After Applying After applying CSP: - browsers will block unauthorized resources - some scripts or assets may fail to load - console warnings or errors may appear This is expected if the policy is too restrictive or incomplete. --- ## How to Verify To verify CSP: 1. Open your browser developer tools 2. Navigate to the Console or Network tab 3. Look for CSP-related messages You may see: - blocked resource warnings - CSP violation messages These help identify what needs adjustment. --- ## How to Revert (Rollback) To revert CSP: 1. Remove or adjust the CSP header from your server configuration 2. Reload your site 3. Confirm that blocked resources are loading again --- ## Common Issues ### Site Functionality Breaks This is the most common issue. To resolve: - identify blocked resources in the browser console - update the policy to allow required sources - apply changes incrementally --- ### Inline Scripts Are Blocked CSP may block inline scripts by default. Options include: - allowing specific inline scripts (with caution) - refactoring scripts to external files --- ### Third-Party Services Stop Working Some services require specific domains to be allowed. To resolve: - identify required domains - update the policy accordingly --- ### Too Many CSP Errors This may indicate: - an overly strict policy - incomplete configuration Start with a simpler policy and expand gradually. --- ## Best Practices - start with a basic policy and refine it - apply changes incrementally - test thoroughly after each update - monitor browser console for violations --- ## Tips - CSP is powerful but requires careful tuning - not all sites need a strict policy immediately - prioritize stability over strictness --- ## What to Do Next If you are considering CSP: 1. Review your site's external dependencies 2. Start with a simple policy 3. Test thoroughly 4. Refine over time --- ## Related - [Security Headers Overview](https://docs.steelwp.com/books/hardening-reference/page/security-headers-overview) - [X-Frame-Options](https://docs.steelwp.com/books/hardening-reference/page/x-frame-options) - [X-Content-Type-Options](https://docs.steelwp.com/books/hardening-reference/page/x-content-type-options) - [Referrer-Policy](https://docs.steelwp.com/books/hardening-reference/page/referrer-policy) - [Safe Rollback Practices](https://docs.steelsecurity.com/books/plugin-guide/page/safe-rollback-practices) # X-Frame-Options ## What This Does This protection controls whether your site can be embedded inside an iframe on another website. It helps prevent unauthorized framing of your content. --- ## Why It Matters Without restrictions, your site can be embedded within another page using an iframe. This can be used for: - clickjacking attacks - tricking users into interacting with hidden elements - overlaying malicious interfaces on top of your site Restricting iframe usage helps protect users from these types of attacks. --- ## When to Apply It This protection is recommended for most websites. Apply it when: - your site should not be embedded on other domains - you want to prevent clickjacking - your site does not rely on being framed externally --- ## When Not to Apply It Do not apply strict restrictions if: - your site must be embedded in another application - you intentionally allow framing (e.g., widgets, integrations) In these cases, more flexible policies may be required. --- ## How Steel Security Applies This Steel Security sets the `X-Frame-Options` HTTP header. Common values include: - `DENY` — prevents all framing - `SAMEORIGIN` — allows framing only on the same domain The appropriate value depends on your site’s requirements. --- ## What to Expect After Applying After applying this protection: - your site cannot be embedded in unauthorized iframes - browsers will block framing attempts - your site functionality will remain unchanged in most cases --- ## How to Verify To verify the protection: 1. Open your browser developer tools 2. Navigate to the Network tab 3. Inspect a page request 4. Look for the `X-Frame-Options` header You should see the configured value (e.g., `DENY` or `SAMEORIGIN`). --- ## How to Revert (Rollback) To revert this protection: 1. Navigate to the hardening section in Steel Security 2. Disable or adjust the control 3. Confirm the change 4. Re-check the response headers --- ## Common Issues ### Site Cannot Be Embedded This is expected if framing is restricted. If embedding is required: - adjust the policy - use a more flexible approach if supported --- ### Header Not Appearing - verify server configuration supports headers - check for CDN or caching layers - ensure no conflicting rules exist --- ### Conflicts with Other Policies - Content Security Policy (CSP) may also control framing - ensure policies are aligned --- ## Related - [Security Headers Overview](https://docs.steelwp.com/books/hardening-reference/page/security-headers-overview) - [Content Security Policy (CSP)](https://docs.steelwp.com/books/hardening-reference/page/content-security-policy-csp) - [Safe Rollback Practices](https://docs.steelsecurity.com/books/plugin-guide/page/safe-rollback-practices) # X-Content-Type-Options ## What This Does This protection prevents browsers from trying to guess (or “sniff”) the content type of a file. It ensures files are interpreted only as the type declared by the server. --- ## Why It Matters Some browsers attempt to determine a file’s type even if it is served incorrectly. This behavior can lead to security issues such as: - executing files as scripts when they should not be - interpreting uploaded content in unintended ways - increasing exposure to cross-site scripting (XSS) attacks Disabling content type sniffing ensures files are handled safely. --- ## When to Apply It This protection is recommended for all websites. Apply it when: - your site serves any type of content - you want to enforce correct content handling - you are following standard web security practices --- ## When Not to Apply It In most cases, this protection should always be applied. Only avoid applying if: - your server is misconfigured and relies on browser sniffing (rare and discouraged) --- ## How Steel Security Applies This Steel Security sets the `X-Content-Type-Options` HTTP header with the value: - `nosniff` This instructs browsers to strictly follow declared content types. --- ## What to Expect After Applying After applying this protection: - browsers will no longer attempt to guess file types - improperly served files may fail to load - your site becomes more resistant to content-based attacks In most cases, there is no visible change. --- ## How to Verify To verify the protection: 1. Open your browser developer tools 2. Navigate to the Network tab 3. Inspect a page request 4. Look for the `X-Content-Type-Options` header You should see: - `nosniff` --- ## How to Revert (Rollback) To revert this protection: 1. Navigate to the hardening section in Steel Security 2. Disable the control 3. Confirm the change 4. Re-check the response headers --- ## Common Issues ### Files Fail to Load This may occur if: - files are served with incorrect MIME types - server configuration is incomplete To resolve: - correct the server’s content-type configuration - ensure files are served with proper headers --- ### No Visible Change This is expected. The protection works at the browser level and may not produce visible differences. --- ### Header Not Appearing - verify server supports header rules - check for CDN or caching layers - confirm configuration was applied correctly --- ## Related - [Security Headers Overview](https://docs.steelwp.com/books/hardening-reference/page/security-headers-overview) - [X-Frame-Options](https://docs.steelwp.com/books/hardening-reference/page/x-frame-options) - [Content Security Policy (CSP)](https://docs.steelwp.com/books/hardening-reference/page/content-security-policy-csp) - [Safe Rollback Practices](https://docs.steelsecurity.com/books/plugin-guide/page/safe-rollback-practices) # Referrer-Policy ## What This Does This protection controls how much referral information is shared when users navigate away from your site. It determines what data is included in the `Referer` header sent to other websites. --- ## Why It Matters When a user clicks a link, their browser may send the previous page’s URL as a referrer. This can expose: - full URLs (including query parameters) - internal paths - sensitive information in links Without a defined policy, more information may be shared than necessary. --- ## When to Apply It This protection is recommended for most websites. Apply it when: - you want to limit information shared with external sites - you are concerned about data leakage through URLs - you want to follow modern privacy best practices --- ## When Not to Apply It You may choose a less restrictive policy if: - your site depends on referral data for analytics - integrations require full referrer information - marketing tools rely on detailed referral tracking --- ## How Steel Security Applies This Steel Security sets the `Referrer-Policy` HTTP header. Common values include: - `no-referrer` — no referrer information is sent - `same-origin` — referrer sent only within your site - `strict-origin-when-cross-origin` — limited referrer for external requests (recommended default) The selected policy balances privacy and functionality. --- ## What to Expect After Applying After applying this protection: - less referral data will be shared with external sites - user privacy is improved - some analytics or tracking tools may receive less information In most cases, there is no visible impact on site functionality. --- ## How to Verify To verify the protection: 1. Open your browser developer tools 2. Navigate to the Network tab 3. Inspect a page request 4. Look for the `Referrer-Policy` header You should see the configured policy value. --- ## How to Revert (Rollback) To revert this protection: 1. Navigate to the hardening section in Steel Security 2. Disable or adjust the control 3. Confirm the change 4. Re-check the response headers --- ## Common Issues ### Analytics Data Is Reduced This may occur if: - a restrictive policy limits referrer information - external tools rely on full URL data To resolve: - choose a less restrictive policy - balance privacy with tracking needs --- ### No Visible Change This is expected. The protection affects how browsers send data, not how your site behaves visually. --- ### Header Not Appearing - verify server supports header rules - check for CDN or caching layers - confirm configuration was applied correctly --- ## Related - [Security Headers Overview](https://docs.steelwp.com/books/hardening-reference/page/security-headers-overview) - [X-Frame-Options](https://docs.steelwp.com/books/hardening-reference/page/x-frame-options) - [X-Content-Type-Options](https://docs.steelwp.com/books/hardening-reference/page/x-content-type-options) - [Content Security Policy (CSP)](https://docs.steelwp.com/books/hardening-reference/page/content-security-policy-csp) - [Safe Rollback Practices](https://docs.steelsecurity.com/books/plugin-guide/page/safe-rollback-practices) # Access & Surface Reduction Access & Surface Reduction # Hide Version Information ## What This Does This protection hides version information for WordPress and related components from public view. It reduces the amount of system information exposed to visitors and automated scanners. --- ## Why It Matters By default, WordPress and some plugins may expose version information in: - HTML source code - meta tags - HTTP headers - scripts and styles This information can help attackers: - identify known vulnerabilities - target specific versions of software - automate attacks against your site Reducing version exposure makes it harder to profile your system. --- ## When to Apply It This protection is recommended for all production websites. Apply it when: - your site is publicly accessible - you want to reduce information disclosure - you are following security best practices --- ## When Not to Apply It In most cases, this protection should always be applied. Only avoid applying if: - you are actively debugging version-related issues - a tool or integration depends on visible version information (rare) --- ## How Steel Security Applies This Steel Security removes or suppresses version information from common sources. This may include: - removing WordPress version meta tags - filtering version query strings from scripts and styles - limiting version exposure in headers This reduces visibility without affecting functionality. --- ## What to Expect After Applying After applying this protection: - version information will no longer appear in page source - automated scanners will have less information about your system - your site functionality will remain unchanged This does not prevent vulnerabilities — it reduces exposure. --- ## How to Verify To verify the protection: 1. View the source of your website 2. Search for version-related strings (e.g., `?ver=` or generator meta tags) 3. Confirm that version details are not visible You may also inspect HTTP headers if applicable. --- ## How to Revert (Rollback) To revert this protection: 1. Navigate to the hardening section in Steel Security 2. Disable the control 3. Confirm the change 4. Refresh your site and re-check the source Version information may become visible again. --- ## Common Issues ### Version Strings Still Appear - some plugins may add their own version parameters - caching may delay visible changes - additional filtering may be required in some environments --- ### No Visible Change This can happen if: - your site was not exposing version information to begin with - your theme or plugins already suppress version output --- ### Debugging Becomes More Difficult If needed: - temporarily revert the change - use server logs or development tools instead --- ## Related - [Disable Debug Mode](https://docs.steelwp.com/books/hardening-reference/page/disable-debug-mode) - [Restrict XML-RPC](https://docs.steelwp.com/books/hardening-reference/page/restrict-xml-rpc) - [Safe Rollback Practices](https://docs.steelsecurity.com/books/plugin-guide/page/safe-rollback-practices) # Restrict Sensitive Endpoints ## What This Does This protection restricts access to sensitive WordPress endpoints that are commonly targeted by automated attacks. It reduces exposure to login, remote access, and system interaction points. --- ## Why It Matters WordPress exposes several endpoints that are frequently targeted, including: - `wp-login.php` - `xmlrpc.php` - REST API endpoints These endpoints can be used for: - brute force login attempts - automated scanning and probing - abuse of authentication mechanisms Restricting access helps reduce unnecessary exposure and attack surface. --- ## When to Apply It This protection is recommended for most production websites. Apply it when: - your site is publicly accessible - you want to reduce automated attack traffic - you do not require unrestricted access to these endpoints --- ## When to Be Cautious Be cautious when applying restrictions if: - you rely on remote access tools - integrations depend on REST or XML-RPC endpoints - your team accesses the site from multiple or changing locations Always test access after applying restrictions. --- ## How Steel Security Applies This Steel Security restricts access to sensitive endpoints using server-level rules. Depending on your environment, this may include: - limiting access by IP or conditions - blocking direct access to specific endpoints - reducing exposure to unauthenticated requests The exact behavior may vary based on server capabilities. --- ## What to Expect After Applying After applying this protection: - unauthorized or automated access attempts will be blocked - login and system endpoints may be less accessible externally - attack surface is reduced Legitimate access should continue to function if properly configured. --- ## How to Verify To verify the protection: 1. Attempt to access a restricted endpoint (e.g., `/wp-login.php` or `/xmlrpc.php`) 2. Confirm that access is limited or blocked under expected conditions Test both: - authorized access (should work) - unauthorized access (should be restricted) --- ## How to Revert (Rollback) To revert this protection: 1. Navigate to the hardening section in Steel Security 2. Disable or adjust the control 3. Confirm the change 4. Re-test access to affected endpoints --- ## Common Issues ### Unable to Log In This may occur if access restrictions are too strict. To resolve: - review access conditions - adjust or revert the restriction - ensure your IP or environment is allowed --- ### Integrations Stop Working Some integrations rely on: - REST API - XML-RPC If affected: - identify the required endpoint - adjust restrictions accordingly - revert if necessary --- ### Endpoint Still Accessible - verify server rules are applied correctly - check for caching or proxy layers - confirm no conflicting configuration exists --- ## Best Practices - restrict only what is not required - test login and integrations after applying - avoid overly aggressive blocking - use rollback if access issues occur --- ## Related - [Restrict XML-RPC](https://docs.steelwp.com/books/hardening-reference/page/restrict-xml-rpc) - [Hide Version Information](https://docs.steelwp.com/books/hardening-reference/page/hide-version-information) - [Safe Rollback Practices](https://docs.steelsecurity.com/books/plugin-guide/page/safe-rollback-practices) # Limit Exposure of System Info ## What This Does This protection reduces the amount of system and environment information exposed by your website. It limits visibility into how your site is configured and how it operates. --- ## Why It Matters Websites often expose system information unintentionally, including: - server details - software versions - file paths - error messages - configuration hints This information can help attackers: - identify vulnerabilities - tailor attacks to your environment - gain insight into your system structure Reducing this exposure makes your site harder to profile and target. --- ## When to Apply It This protection is recommended for all production websites. Apply it when: - your site is publicly accessible - you want to reduce information disclosure - you are following security best practices --- ## When to Be Cautious Be cautious when: - actively debugging issues - working in a development environment - relying on visible system output for troubleshooting In these cases, temporary visibility may be useful. --- ## How Steel Security Applies This Steel Security limits system information exposure through a combination of protections, which may include: - suppressing error output - reducing server or application details in responses - limiting visible system metadata The exact implementation depends on your environment and configuration. --- ## What to Expect After Applying After applying this protection: - less system information will be visible publicly - error messages will be less detailed or hidden - your site will reveal less about its internal structure Functionality should remain unchanged. --- ## How to Verify To verify the protection: 1. Trigger or observe areas where system information may appear 2. Confirm that sensitive details are not exposed Check for: - error messages - page source output - response headers --- ## How to Revert (Rollback) To revert this protection: 1. Navigate to the hardening section in Steel Security 2. Disable or adjust the control 3. Confirm the change 4. Re-test visibility of system information --- ## Common Issues ### Debug Information Is No Longer Visible This is expected. System output is being suppressed for security. If needed: - temporarily revert the change - use logs or development tools instead --- ### No Visible Change This may occur if: - your environment was already configured securely - system information was not being exposed --- ### Incomplete Protection Some system information may still be exposed depending on: - server configuration - plugins or themes - hosting environment Additional hardening may be required. --- ## Best Practices - avoid exposing system details in production - use logs instead of visible errors - apply protections consistently across environments - combine with other hardening controls --- ## Related - [Disable Debug Mode](https://docs.steelwp.com/books/hardening-reference/page/disable-debug-mode) - [Hide Version Information](https://docs.steelwp.com/books/hardening-reference/page/hide-version-information) - [Security Headers Overview](https://docs.steelwp.com/books/hardening-reference/page/security-headers-overview) - [Safe Rollback Practices](https://docs.steelsecurity.com/books/plugin-guide/page/safe-rollback-practices) # Server-Aware Hardening Server-Aware Hardening # Apache (.htaccess) Hardening ## What This Covers This page explains how Steel Security applies hardening using Apache `.htaccess` configuration. It provides insight into how server-level protections are implemented for Apache-based environments. --- ## What Is .htaccess `.htaccess` is a configuration file used by Apache web servers. It allows you to define rules that control: - access to files and directories - request handling - security behavior These rules are applied before WordPress processes a request. --- ## Why Server-Level Hardening Matters Server-level rules provide protection before your application is reached. This helps: - block malicious requests early - reduce load on WordPress - enforce consistent security behavior It is one of the most effective ways to apply security controls. --- ## How Steel Security Uses .htaccess Steel Security applies hardening by adding rules to your `.htaccess` file. These rules may include: - blocking access to sensitive files - disabling directory listing - restricting execution in specific directories - limiting access to endpoints Changes are applied in a controlled and reversible way. --- ## What to Expect After applying hardening via `.htaccess`: - requests may be blocked before reaching WordPress - certain files or endpoints may become inaccessible - your site will enforce stricter access rules Most changes are immediate. --- ## How to Verify To verify `.htaccess` hardening: 1. Test access to restricted files or endpoints 2. Confirm that access is denied where expected 3. Observe server responses (e.g., 403 Forbidden) You can also inspect behavior through your browser or server logs. --- ## How to Revert (Rollback) To revert `.htaccess` changes: 1. Disable the relevant hardening control in Steel Security 2. Confirm the change 3. Test affected areas of your site Steel Security will remove or adjust the rules it applied. --- ## Common Issues ### Site Becomes Inaccessible This may occur if: - rules conflict with your hosting environment - restrictions are too aggressive To resolve: - revert the most recent change - review applied rules - test incrementally --- ### Rules Do Not Take Effect - ensure `.htaccess` overrides are enabled (`AllowOverride`) - confirm Apache is reading the file - check for conflicting configurations --- ### Unexpected Behavior - review recent hardening changes - test one rule at a time - check server logs for details --- ## Best Practices - apply changes incrementally - test after each change - keep a backup of your `.htaccess` file - avoid manual edits unless necessary - use Steel Security controls for consistency --- ## When This Applies This page is relevant if your server uses Apache. If you are unsure: - check with your hosting provider - review server response headers - consult your hosting control panel --- ## Related - [Nginx Hardening](https://docs.steelwp.com/books/hardening-reference/page/nginx-hardening) - [IIS (web.config) Hardening](https://docs.steelwp.com/books/hardening-reference/page/iis-webconfig-hardening) - [Applying Hardening Safely](https://docs.steelsecurity.com/books/getting-started/page/applying-hardening-safely) - [Safe Rollback Practices](https://docs.steelsecurity.com/books/plugin-guide/page/safe-rollback-practices) # Nginx Hardening ## What This Covers This page explains how Steel Security supports hardening in Nginx-based environments. It provides guidance on applying server-level protections where automatic configuration is not available. --- ## What Is Nginx Configuration Nginx uses centralized server configuration files instead of per-directory configuration like `.htaccess`. This means: - rules are defined at the server level - changes typically require server access - configuration updates often require a reload or restart --- ## Why Server-Level Hardening Matters Server-level rules provide protection before requests reach WordPress. This helps: - block malicious traffic early - reduce unnecessary processing - enforce consistent security policies --- ## How Steel Security Works with Nginx Unlike Apache, Nginx does not support dynamic configuration through application-level changes. As a result: - Steel Security cannot directly modify Nginx configuration - hardening must be applied manually or through your hosting environment - Steel Security provides guidance for implementing equivalent protections --- ## What Steel Security Can Do Steel Security can still: - identify risks through scans - recommend hardening actions - provide guidance for server-level implementation This ensures you can still improve security even without automatic rule application. --- ## What to Expect When using Nginx: - some hardening controls may require manual steps - changes will not apply automatically through the plugin - server configuration must be updated separately --- ## How to Apply Hardening To apply hardening in Nginx: 1. Identify the recommended protection in Steel Security 2. Locate your Nginx server configuration 3. Apply the appropriate rules manually 4. reload or restart Nginx 5. test your site functionality --- ## How to Verify To verify Nginx hardening: 1. Test access to restricted files or endpoints 2. Confirm that access is denied where expected 3. inspect server responses (e.g., 403 Forbidden) You may also review server logs for confirmation. --- ## How to Revert (Rollback) To revert changes: 1. Remove or adjust the configuration from your Nginx setup 2. reload or restart the server 3. re-test affected functionality --- ## Common Issues ### Changes Do Not Take Effect - ensure the configuration was reloaded - confirm the correct server block was updated - check for conflicting rules --- ### Site Functionality Breaks - revert the most recent change - review applied rules - test incrementally --- ### Limited Access to Server Configuration - some hosting environments restrict Nginx access - consult your hosting provider - use available control panel tools if provided --- ## Best Practices - apply changes incrementally - test after each update - keep backups of configuration files - document changes where possible --- ## When This Applies This page is relevant if your server uses Nginx. If you are unsure: - check with your hosting provider - review server response headers - inspect your hosting environment --- ## Related - [Apache (.htaccess) Hardening](https://docs.steelwp.com/books/hardening-reference/page/apache-htaccess-hardening) - [IIS (web.config) Hardening](https://docs.steelwp.com/books/hardening-reference/page/iis-webconfig-hardening) - [Applying Hardening Safely](https://docs.steelsecurity.com/books/getting-started/page/applying-hardening-safely) - [Safe Rollback Practices](https://docs.steelsecurity.com/books/plugin-guide/page/safe-rollback-practices) # IIS (web.config) Hardening ## What This Covers This page explains how Steel Security applies hardening using IIS `web.config` configuration. It provides insight into how server-level protections are implemented for Microsoft IIS environments. --- ## What Is web.config `web.config` is a configuration file used by Microsoft IIS servers. It allows you to define rules that control: - access to files and directories - request handling - security behavior These rules are processed by the server before requests reach WordPress. --- ## Why Server-Level Hardening Matters Server-level rules provide protection before your application is reached. This helps: - block malicious requests early - reduce load on WordPress - enforce consistent security behavior --- ## How Steel Security Uses web.config Steel Security applies hardening by updating the `web.config` file. These updates may include: - blocking access to sensitive files - restricting directory access - limiting execution in specific locations - controlling access to endpoints Changes are applied in a controlled and reversible way. --- ## What to Expect After applying hardening via `web.config`: - certain requests may be blocked before reaching WordPress - restricted files or endpoints will return errors (e.g., 403 Forbidden) - security rules are enforced consistently Most changes take effect immediately. --- ## How to Verify To verify `web.config` hardening: 1. Test access to restricted files or endpoints 2. Confirm that access is denied where expected 3. Observe server responses You may also review IIS logs if available. --- ## How to Revert (Rollback) To revert changes: 1. Navigate to the hardening section in Steel Security 2. Disable the relevant control 3. Confirm the change 4. Test affected areas Steel Security will remove or adjust the rules it applied. --- ## Common Issues ### Site Becomes Inaccessible This may occur if: - rules are too restrictive - configuration conflicts exist To resolve: - revert the most recent change - review applied rules - test incrementally --- ### Changes Do Not Apply - ensure IIS is reading the updated `web.config` - check for higher-level configuration overrides - verify file permissions --- ### Unexpected Behavior - review recent changes - test one rule at a time - check server logs for details --- ## Best Practices - apply changes incrementally - test after each change - keep a backup of your `web.config` file - avoid manual edits unless necessary - use Steel Security controls for consistency --- ## When This Applies This page is relevant if your server uses Microsoft IIS. If you are unsure: - check with your hosting provider - review your server environment - inspect hosting configuration tools --- ## Related - [Apache (.htaccess) Hardening](https://docs.steelwp.com/books/hardening-reference/page/apache-htaccess-hardening) - [Nginx Hardening](https://docs.steelwp.com/books/hardening-reference/page/nginx-hardening) - [Applying Hardening Safely](https://docs.steelsecurity.com/books/getting-started/page/applying-hardening-safely) - [Safe Rollback Practices](https://docs.steelsecurity.com/books/plugin-guide/page/safe-rollback-practices) # Defense in Depth with Steel Security ## What This Means Security is not achieved through a single setting or control. Effective protection comes from applying multiple layers that work together to reduce risk. This approach is known as **defense in depth**. --- ## Why Layered Security Matters No single protection can stop every type of attack. For example: - blocking file access does not stop script injection - hiding system information does not prevent brute force attempts - restricting endpoints does not protect against file uploads Each control addresses a different type of risk. When combined, they create a stronger and more resilient system. --- ## How Steel Security Applies This Approach Steel Security is designed around layered security. Instead of relying on one feature, it applies multiple protections across key areas: --- ### File Protection Protects sensitive files from being accessed directly. Examples include: - configuration files - backup files - restricted directories --- ### Execution Control Prevents unauthorized code from running. Examples include: - blocking PHP execution in upload directories - preventing direct access to internal scripts --- ### Surface Reduction Reduces the number of exposed entry points. Examples include: - restricting sensitive endpoints - disabling unused features - limiting external access --- ### Information Control Limits what your site reveals about itself. Examples include: - hiding version information - suppressing system details - reducing visible metadata --- ### Security Headers Adds browser-level protections. Examples include: - clickjacking protection - content type enforcement - referrer control - content security guidance --- ### Server-Level Enforcement Applies rules before WordPress is reached. Examples include: - Apache `.htaccess` rules - IIS `web.config` rules - Nginx configuration guidance --- ## What This Means in Practice When these layers are combined: - attackers have fewer entry points - exposed information is minimized - malicious actions are more likely to be blocked - successful attacks become significantly harder Even if one layer is bypassed, others remain in place. --- ## A Practical Example Consider a common attack scenario: 1. A malicious file is uploaded 2. The attacker attempts to execute it 3. The attacker tries to gather system information With layered protection: - execution is blocked in upload directories - direct access to PHP files is restricted - system details are not exposed Each layer reduces the chance of success. --- ## How to Use This Approach To apply defense in depth effectively: 1. Enable multiple hardening controls 2. Avoid relying on a single protection 3. Test your site after applying changes 4. apply changes incrementally 5. use rollback if needed --- ## Key Principle Security is not about perfection. It is about reducing risk across multiple areas. Steel Security helps you achieve this by applying practical, layered protections that work together. --- ## What to Do Next - review your enabled hardening controls - ensure coverage across all categories - continue refining your configuration over time --- ## Related - [Safe Rollback Practices](https://docs.steelsecurity.com/books/plugin-guide/page/safe-rollback-practices) - [Applying Hardening Safely](https://docs.steelsecurity.com/books/getting-started/page/applying-hardening-safely) - [Security Headers Overview](https://docs.steelwp.com/books/hardening-reference/page/security-headers-overview)