Skip to main content

Customer Pentesting Their Code Using Local Environment

To facilitate penetration testing (pentesting) of the customizations owned by the customer running on the Arc XP platform, we provide two options:

  • Test against the publicly available website: This involves testing through CDN/WAF and other controls, without any allow-listing or direct access to the origin. This approach assesses the security stance on the public internet and is described in Customer Security Testing

  • Test against a local, Docker container-hosted development environment: This method assesses the website for code-level vulnerabilities, such as the OWASP Top 10, that may otherwise be partially blocked by compensating controls, such as a WAF.

This document focuses on local testing.

Discovering web application issues caused by coding mistakes is best done in a controlled testing environment. Customers can test using a local Docker container running components that execute customized code and deliver end-user content. Running these components locally allows the pentesting team to simulate real-world attacks and identify potential security weaknesses without Delivery (CDN/WAF/Rate limiting) controls in place. This setup still communicates back to Arc XP APIs to access content, ensuring that the pentest accurately reflects the operational environment.

Security Testing Conditions

Arc XP allows this setup to be used for security testing of customized code, provided the following conditions are met:

  • Local Environment Isolation: The local environment must be isolated and not exposed to the public internet. Internet exposure creates a path to your backend APIs without standard controls.

  • Test Your Code Only: The setup includes Arc XP administration components normally accessible through the admin interface. We test these regularly. You get the best value from the pentest if you limit the scope to your own code by targeting http://localhost/pf/ in your testing.

  • Sandbox Only: You may only connect your local environment to your “sandbox” APIs. No production connectivity is allowed. Because pentesting can sometimes be disruptive and cause back-end bottlenecks, your production environment might be impacted if you connect to the production backend.

  • API Token Management: Create API tokens specifically for this test and delete them afterward. API tokens allow access to your content. Should the token be accessed by an unauthorized party, your content may be changed by them. To prevent that exposure, tokens should be deleted when no longer needed.

Customer Security Testing guidelines still apply.

Setting Up for the Test

  1. Running the local environment under pentesting load may be compute-intensive. We suggest picking a good machine for this purpose.

  2. Review How To Run PageBuilder Engine Locally - Starting with my organization's live bundle and pages.

  3. Either download the bundle from the live Page Builder instance, as shown in the video above, or obtain it from your source code repository.

  4. Create an API Key for testing. Instructions can be found in the document/video above.

    Caution

    Ensure you are accessing the sandbox environment and not production.

  5. Use http://localhost/pf/ as your testing target.

In this section: