PHP2GO SECURITY POLICY
The service is built around safe handling of third-party PHP code: archives are checked, commands are limited, and data access should be minimal.
This is working public product text. Before real international payments and advertising, review it with counsel for your jurisdiction, company, payment providers, and tax rules.
This Security Policy describes the organizational, technical and procedural measures that are applied or may be applied in php2go to protect accounts, projects, source code, build artifacts, technical logs and the service infrastructure.
This Policy applies together with the Terms of Service, Privacy Policy, Acceptable Use Policy, Payment and Refund Policy, Data Deletion Policy and other documents published on the website.
This document does not disclose internal technical details that could weaken the security of the service. The specific set of measures may change as the product, infrastructure, threats and legal requirements evolve.
Before publication, this document should be reviewed by legal counsel and aligned with the security measures actually implemented in the php2go infrastructure.
1. Purpose and scope
1.1.This section establishes rules and approaches for protecting: data, projects, accounts, artifacts, payment operations, technical logs and service infrastructure.
1.2.The Administration may apply reasonable technical, organizational and procedural measures, including: documenting rules, separating responsibilities, controlling access and regularly updating procedures.
1.3.The user must: comply with this Policy, the Terms of Service, documentation and applicable law.
1.4.If requirements are violated, an incident is suspected or a security threat exists, the Administration may: restrict access, suspend processing, request information, remove dangerous materials or apply other protective measures.
2. Core security principles
2.1.This section establishes rules and approaches for protecting: cloud processing of PHP projects, handling of source code, generation of artifacts and interaction with payment providers.
2.2.The Administration may apply reasonable technical, organizational and procedural measures, including: least privilege, separation of roles, activity control, event monitoring and continuous improvement of protective mechanisms.
2.3.The user must: understand that security is a shared responsibility and independently protect their account, project, secrets and artifacts.
2.4.If requirements are violated, an incident is suspected or a security threat exists, the Administration may: temporarily restrict functions, change limits, strengthen checks or stop dangerous activity.
3. Shared responsibility model
3.1.This section establishes rules and approaches for protecting: the boundaries of responsibility between the Administration and the user when using php2go.
3.2.The Administration may apply reasonable technical, organizational and procedural measures, including: protection of server infrastructure, authentication systems, upload mechanisms, build environment and internal administrative tools.
3.3.The user must: use reliable credentials, have rights to the uploaded project, avoid unnecessary secrets in archives and verify build results.
3.4.If requirements are violated, an incident is suspected or a security threat exists, the Administration may: refuse project processing if the risk arose from the user’s actions or violation of service rules.
4. Account security
4.1.This section establishes rules and approaches for protecting: the user account, email, password, sessions, tokens and authentication methods.
4.2.The Administration may apply reasonable technical, organizational and procedural measures, including: login attempt limits, suspicious activity checks, email confirmation, session management and forced password reset if compromise risk exists.
4.3.The user must: use a strong password, not transfer access to third parties and immediately report suspected compromise.
4.4.If requirements are violated, an incident is suspected or a security threat exists, the Administration may: block a session, reset a password, temporarily restrict an account or request additional verification.
5. Access management and internal access
5.1.This section establishes rules and approaches for protecting: administrative functions, infrastructure, user projects and service data.
5.2.The Administration may apply reasonable technical, organizational and procedural measures, including: role separation, individual accounts, privilege control, administrative action logging and periodic access review.
5.3.The user must: not attempt to access other accounts, projects, artifacts or internal systems of the service.
5.4.If requirements are violated, an incident is suspected or a security threat exists, the Administration may: suspend an account, delete tokens, block requests and preserve information for investigation.
6. Security of project uploads
6.1.This section establishes rules and approaches for protecting: ZIP archives, source code, dependencies, configurations and other files uploaded to the service.
6.2.The Administration may apply reasonable technical, organizational and procedural measures, including: checking format, size, structure, file count, technical limits and signs of dangerous behavior.
6.3.The user must: upload only lawful projects to which they have rights and exclude unnecessary secrets, database dumps and production configurations.
6.4.If requirements are violated, an incident is suspected or a security threat exists, the Administration may: reject an upload, stop processing, delete a file, block a project or restrict an account.
7. Source code, secrets and sensitive data
7.1.This section establishes rules and approaches for protecting: source code, private keys, tokens, passwords, payment keys, personal data and other sensitive information.
7.2.The Administration may apply reasonable technical, organizational and procedural measures, including: access restriction, service logging, temporary processing, deletion of temporary files and procedures for detecting dangerous secrets.
7.3.The user must: not include secrets that are not required for the build and immediately rotate or revoke them if accidentally uploaded.
7.4.If requirements are violated, an incident is suspected or a security threat exists, the Administration may: delete dangerous files, stop a build, request proof of rights or recommend rotating keys and tokens.
8. Build environment and process isolation
8.1.This section establishes rules and approaches for protecting: the build environment, temporary files, cache, intermediate data, system commands and execution resources.
8.2.The Administration may apply reasonable technical, organizational and procedural measures, including: restrictions on file system, network, system commands, execution time, memory, disk, processes and other resources.
8.3.The user must: not upload code intended to escape the environment, exploit vulnerabilities, access other users’ data or interfere with infrastructure.
8.4.If requirements are violated, an incident is suspected or a security threat exists, the Administration may: immediately stop a build, delete artifacts, restrict an account and report information to competent authorities if necessary.
9. Infrastructure and network security
9.1.This section establishes rules and approaches for protecting: servers, domains, network connections, databases, task queues, storage systems and administrative panels.
9.2.The Administration may apply reasonable technical, organizational and procedural measures, including: software updates, network access restriction, firewalls, port control, segmentation and availability monitoring.
9.3.The user must: not perform scanning, load tests, attacks or infrastructure research without prior written permission.
9.4.If requirements are violated, an incident is suspected or a security threat exists, the Administration may: restrict IP addresses, requests, functions, accounts or builds that threaten stability or security.
10. Data transmission and encryption
10.1.This section establishes rules and approaches for protecting: data transmission between the user and the website, account area, upload forms, payment pages and other interfaces.
10.2.The Administration may apply reasonable technical, organizational and procedural measures, including: secure channels, HTTPS/TLS, token protection, restricted access to service data and additional protective mechanisms where provided by architecture.
10.3.The user must: use an up-to-date browser, secure connection, trusted device and avoid sending projects through unsafe networks.
10.4.If requirements are violated, an incident is suspected or a security threat exists, the Administration may: suspend unsafe operations, revoke tokens or require re-authentication.
11. Logs, monitoring and abuse detection
11.1.This section establishes rules and approaches for protecting: technical logs, account events, build statuses, errors, payment events and interface actions.
11.2.The Administration may apply reasonable technical, organizational and procedural measures, including: logging, monitoring suspicious activity, analyzing limit bypass attempts, detecting malicious projects and investigating errors.
11.3.The user must: understand that logs may be stored for security, diagnostics, accounting, protection of rights, legal compliance and dispute resolution.
11.4.If requirements are violated, an incident is suspected or a security threat exists, the Administration may: retain necessary information, block suspicious actions, cancel operations or restrict access.
12. Backups, storage and deletion
12.1.This section establishes rules and approaches for protecting: backups, projects, artifacts, temporary files, cache, logs and service data.
12.2.The Administration may apply reasonable technical, organizational and procedural measures, including: backup of selected components, recovery from failures, retention control and automatic deletion of outdated materials.
12.3.The user must: store source projects and necessary artifacts independently outside the service and not use the service as the only storage.
12.4.If requirements are violated, an incident is suspected or a security threat exists, the Administration may: delete data according to retention periods, when limits are exceeded, at the user’s request or for security reasons.
13. Detection of malicious code and prohibited activity
13.1.This section establishes rules and approaches for protecting: malicious code, phishing, miners, exploits, backdoor components, spam, DDoS and other prohibited activity.
13.2.The Administration may apply reasonable technical, organizational and procedural measures, including: filters, heuristics, signatures, manual analysis, automated checks and abuse response measures.
13.3.The user must: not use the service for illegal, malicious, fraudulent or dangerous activity.
13.4.If requirements are violated, an incident is suspected or a security threat exists, the Administration may: stop a build, delete a project, block an account, refuse service and retain information for investigation.
14. Third-party providers and external services
14.1.This section establishes rules and approaches for protecting: hosting providers, data centers, payment providers, email services, monitoring, analytics and authentication systems.
14.2.The Administration may apply reasonable technical, organizational and procedural measures, including: selection of providers with regard to reliability, availability, security, reputation, technical capabilities and applicable requirements.
14.3.The user must: understand that some operations may be governed by third-party rules, especially payments, authentication or email notifications.
14.4.If requirements are violated, an incident is suspected or a security threat exists, the Administration may: change a provider, restrict a function, suspend integration or notify the user of material changes.
15. Incident response
15.1.This section establishes rules and approaches for protecting: events that may lead to unauthorized access, loss, alteration, disclosure of data, availability disruption or infrastructure threat.
15.2.The Administration may apply reasonable technical, organizational and procedural measures, including: event confirmation, containment, cause elimination, service restoration, impact analysis and recurrence prevention.
15.3.The user must: immediately report suspicious events and provide reasonably necessary information for verification.
15.4.If requirements are violated, an incident is suspected or a security threat exists, the Administration may: restrict access, disable functions, revoke tokens, reset passwords, stop builds or notify affected users.
16. Vulnerability reporting
16.1.This section establishes rules and approaches for protecting: vulnerabilities in the website, account area, API, project upload, build environment, authentication and other service components.
16.2.The Administration may apply reasonable technical, organizational and procedural measures, including: receiving reports at security@p2g.dev or admin@p2g.dev, verifying facts, prioritizing fixes and safe interaction with the researcher.
16.3.The user must: not use a discovered vulnerability to access other users’ data, disrupt the service, escalate privileges or publicly disclose it before a fix.
16.4.If requirements are violated, an incident is suspected or a security threat exists, the Administration may: stop cooperation with a researcher if testing violates law, service rules or third-party security.
17. User security obligations
17.1.This section establishes rules and approaches for protecting: user behavior when uploading projects, running builds, downloading artifacts and using compilation results.
17.2.The Administration may apply reasonable technical, organizational and procedural measures, including: rules explanation, documentation, technical restrictions, support and tools for deleting or restricting projects.
17.3.The user must: verify dependencies, licenses, configuration, environment variables, artifacts and build results before production use.
17.4.If requirements are violated, an incident is suspected or a security threat exists, the Administration may: restrict use of the service if obligations are violated or a threat is created for the service, users or third parties.
18. Limitations and no absolute guarantee
18.1.This section establishes rules and approaches for protecting: residual risks of cloud source-code processing, network risks, configuration errors, human factors and external provider actions.
18.2.The Administration may apply reasonable technical, organizational and procedural measures, including: reasonable protective measures, without guaranteeing complete absence of threats, errors, attacks, vulnerabilities, leaks or failures.
18.3.The user must: understand the risks of a cloud service and independently assess whether php2go is suitable for their projects and security requirements.
18.4.If requirements are violated, an incident is suspected or a security threat exists, the Administration may: limit liability within the Terms of Service and applicable law.
19. Changes to this Policy
19.1.This section establishes rules and approaches for protecting: updates to this Policy due to service development, infrastructure changes, new threats or legal changes.
19.2.The Administration may apply reasonable technical, organizational and procedural measures, including: publication of a new version on the website, indication of the effective date and additional user notice for material changes.
19.3.The user must: independently monitor current document versions and stop using the service if they disagree with changes.
19.4.If requirements are violated, an incident is suspected or a security threat exists, the Administration may: apply the updated version after it takes effect, unless mandatory law requires otherwise.
20. Contacts and version priority
20.1.This section establishes rules and approaches for protecting: security requests, incident reports, vulnerability reports and data protection inquiries.
20.2.The Administration may apply reasonable technical, organizational and procedural measures, including: receiving requests through security@p2g.dev or admin@p2g.dev, requesting additional information and verifying the requester’s authority.
20.3.The user must: provide account email, problem description, event date and time, project or build identifier, technical details and safe reproduction steps.
20.4.If requirements are violated, an incident is suspected or a security threat exists, the Administration may: apply the Russian version as prevailing in case of translation inconsistencies, unless mandatory applicable law requires otherwise.
In case of any inconsistency between translations and the Russian version of this Policy, the Russian version shall prevail, unless mandatory applicable law requires otherwise.
If you need a copy of terms, a data request, a copyright complaint, or a payment question, contact support.
mailContact support