Web Pioneer Trust Center

1. 01 Engineer
2. 02 Git repository
3. 03 Code review
4. 04 Automated build and test
5. 05 Staging
6. 06 Approval
7. 07 Production
8. 08 Monitoring

Environment separation

Serious work does not happen on the live server. We separate development, staging and production, each with its own configuration, access and data.

• A local development environment per engineer, with no access to real data.
• A staging environment that mirrors production, used for review and acceptance before release.
• A production environment whose credentials, configuration and secrets are entirely separate from the rest.
• Staging environments are kept out of search engines and closed to public access.

Change management

Every change to a live system has a known path, a reason, an expected impact and a way back.

• Changes are described and reviewed before they are applied, not while they are being applied.
• Substantial changes are exercised in staging first.
• Every release has a way back, either a previous version or a restore from backup.
• Changes that affect users are timed with the client in advance.
• Urgent security changes may be applied immediately and reported to the client straight afterwards.
• Any production change is traceable: who applied it, when, and what changed.

Source code security

The code is the product. We treat it that way.

• Repositories are private by default, never public.
• Repository access is role-based and granted only to people working on that project.
• Two-factor authentication is enabled where the repository host supports it.
• The main branch is protected: changes enter through a reviewed merge request.
• Access is revoked as soon as someone stops working on a project or leaves the company.
• Credentials are not written into the code; they are read from environment configuration.
• Repository backups are kept independently of the hosting platform itself.

Production access

This is the part procurement teams usually ask about, so here is the plain answer.

• Production access is restricted and is not handed automatically to everyone on the project.
• Server login is by SSH key rather than password, behind a firewall.
• Privileges are granted by responsibility and narrowed to the minimum that does the job.
• Access is removed when the need ends or the person stops working on the project.
• Production changes are traceable: who acted, when, and what changed.
• Clients who prefer to keep ownership of their own infrastructure grant us scoped access that they can revoke at any time.

Identity and access management

Shared accounts are the fastest way to lose the ability to tell who did what.

• A separate account per person, not one account shared across the team.
• Two-factor authentication is enabled on the services that support it.
• Passwords and secrets live in a password manager, not in files or chat messages.
• Periodic review of who has access to what, and removal of anything no longer needed.
• Immediate revocation of all accounts when someone leaves.

Infrastructure security

The following applies to servers we host or manage under a support agreement. Infrastructure owned by the client is run according to the client's own policy.

• Hardened servers: unused ports closed and unnecessary services disabled.
• A host firewall with automatic blocking of repeated failed login attempts.
• A regular security-update cycle for the operating system and server packages.
• Scheduled malware and file-integrity scanning on the servers we manage.
• A CDN, a web application firewall and denial-of-service protection in front of public sites.
• TLS on all public traffic, with managed certificates that renew automatically.
• Account isolation on shared servers so one site cannot reach another site's files.

Application security

We build against the OWASP Top Ten, the industry's standard list of the ten most common web application risks, and we address them in the code rather than only in a document.

• Authorisation checked server-side on every request, not only in the interface.
• Input validation and output escaping against injection and cross-site scripting.
• Parameterised queries through the database layer instead of string-built SQL.
• Secure session handling: expiry, identifier rotation on login, and protected cookies.
• Passwords stored hashed with modern algorithms, never encrypted and never in plain text.
• Rate limiting on sensitive endpoints such as login and password reset.
• Controlled file uploads: restricted types and sizes, and no execution of what is uploaded.
• Security response headers and cross-site request forgery protection.
• APIs documented and protected with authentication, authorisation and rate limits.

Mobile application security

The app is not the security boundary. The server is.

• All server communication over HTTPS, with no exceptions in shipped builds.
• Authorisation is enforced on the server; hiding an element in the interface is never the control.
• Access tokens are kept in the platform's secure store, with expiry and refresh.
• Permissions are requested when they are actually needed, not all at once on first launch.
• What is stored on the device is kept to the minimum the app genuinely needs.
• Signing keys are held in protected storage and handed to the client at final delivery.

Payments and card data

The single most important thing to know about any store we build: card details do not pass through us at all.

• Payment runs through a licensed gateway, with the customer redirected to the gateway's page or an element the gateway hosts.
• Card numbers and security codes are never stored, never logged, and never traverse our servers.
• What we keep is the transaction reference and its status, which is what reconciliation actually requires.
• Gateway callbacks are verified for authenticity and amount before an order is treated as paid.
• Gateway keys live in server environment configuration, not in the code and not in an admin panel.

Data protection

Your customers' data is not our data, and we treat it accordingly.

• Data encrypted in transit over TLS on all public connections.
• Backups encrypted at rest.
• Each client in a separate database and server account; client data is not commingled.
• Access to production data is limited to people with a live task that needs it, not standing access.
• We do not copy production data into development environments unless personal data has been masked first.
• Confidentiality obligations bind the company and everyone working on the project.
• At the end of an engagement we hand over the data and delete our copies on the client's instruction.

Secrets management

The most common leak is not a breach. It is a key left inside a code repository.

• API keys, access tokens and database passwords are not written into the code.
• Secrets are read from environment files kept outside the repository and explicitly excluded from it.
• Configuration files are protected at the server level so they cannot be fetched from a browser.
• Different keys per environment: staging never carries production keys.
• Immediate rotation of any key suspected of exposure.

Backups and recovery

A backup that has never been restored is not a backup. The schedule and retention for each system are set in its support agreement.

• Daily file and database backups for the systems we host.
• Backups are stored separately from the server itself, not on the same disk.
• Encrypted incremental backups with a retention policy that allows recovery from more than one point in time.
• Integrity checks on the backups, because a corrupt backup is worse than no backup.
• The ability to rebuild a server from scratch: configuration, code and data are all recoverable.

Monitoring and observability

The monitoring scope depends on each system's support agreement. The controls below are constant; the tools named are what we run today and may vary with a project's infrastructure.

• External uptime probes, so an outage is caught before a user reports it.
• Server and application metrics collected into dashboards. Our current tooling: Prometheus and Grafana.
• Application errors tracked as they happen, with repeated errors grouped. Our current tool: a self-hosted Sentry.
• Server log analysis to spot abnormal patterns and abusive crawler traffic.
• Automated alerts when availability, performance or error-rate thresholds are crossed.
• Monitoring of TLS certificate validity and domain expiry dates.

Vulnerability and patch management

Most compromises we have cleaned up were not a novel vulnerability. They were an old component nobody updated.

• A regular update cycle for dependencies and plugins on the systems we manage.
• Tracking of published vulnerabilities in the components we use.
• Remediation prioritised by severity and exploitability rather than by arrival order.
• Substantial updates tested in staging before they reach production.
• Application and infrastructure penetration testing is available as a separate engagement; it is not automatically included in every project.

Quality assurance

Trust is not only security. A system that behaves incorrectly costs you as much as one that is breached.

• Code review before merge for substantial changes.
• Automated tests for critical logic, running inside the deployment pipeline.
• Manual testing of the main journeys and edge cases before handover.
• Regression testing after large changes to confirm nothing that worked has broken.
• API and third-party integration testing independent of the user interface.
• Compatibility testing across browsers and devices, and in both Arabic and English directions.
• Performance and load-time testing before launch for systems expecting real traffic.
• Client acceptance on staging before anything is released to production.

Business continuity

The practical question is: what happens if the engineer who built this disappears? The answer must not be a disaster.

• Every project documented well enough for another engineer to pick it up: architecture, configuration, deployment steps.
• Code lives in a shared repository, not on one person's machine.
• More than one engineer is familiar with each system under support.
• Infrastructure can be rebuilt from backups and documentation.
• An out-of-hours emergency channel for systems covered by a support agreement.

Employee access, confidentiality and offboarding

We sign a non-disclosure agreement before receiving any sensitive project material.

• A non-disclosure agreement is executed before any sensitive information is shared with us.
• Confidentiality obligations extend to everyone working on the project, not to the company alone.
• Access is granted by responsibility; nobody sees what their job does not require.
• All accounts and privileges are revoked when someone leaves.
• We do not use a client's name or material in marketing without permission.

Technology providers

Any modern system depends on third parties. Transparency means knowing who they are before you sign, not after.

• Depending on a project's architecture, a system may rely on providers for cloud hosting, email, payments, analytics, monitoring or messaging.
• Providers are selected according to project requirements and disclosed to the client where relevant.
• A client can require or exclude a specific provider, including a requirement that data stay within a defined geography.
• A project can run entirely inside a cloud account the client owns in their own name.

Ownership of code, data and infrastructure

Our standard position: on full payment, the source code, designs and data belong to the client. The final terms are governed by the signed agreement for each project.

• Source code is handed over with its full repository history, not as a zip file with no record.
• Editable design files are handed over too, not only exported images.
• Data belongs to the client in all cases and is exported in a usable format on request.
• Domains, hosting accounts and app-store accounts can be in the client's name from day one, and we recommend that.
• Application signing keys are handed to the client at final delivery.
• Open-source components remain under their own licences, which does not restrict your use of the system.

Security, backup, monitoring, recovery objectives and response commitments vary by engagement and are defined in the applicable contract or managed-services agreement. This page describes our standard engineering practices and should not be interpreted as a service level agreement unless explicitly incorporated into an agreement.

Also: what is described here applies to systems we build or manage. An inherited system handed to us by another team may not meet these controls on day one, and the first thing we do is tell you where the gaps are rather than paper over them.

If you believe you have found a security issue in a system Web Pioneer owns or operates, contact us before publishing it anywhere else.

support@web-pioneer.com

Include enough detail for us to reproduce it. We will acknowledge receipt and come back to you with what we find.

We ask that you do not use real user data, do not disrupt the service, and do not publish details before the issue is fixed. We do not run a paid bounty programme, and we will not pretend otherwise.

Who owns the source code?

The client, on full payment. The code is handed over with its repository history, along with the editable design files. The final terms are governed by the signed project agreement.

Will Web Pioneer sign an NDA?

Yes. We sign the NDA before receiving any sensitive project material, not after work has started. You can send us your template or use ours.

Can our infrastructure stay under our own ownership?

Yes, and it is what we recommend. Domains, cloud, hosting and app-store accounts can be in your name from day one, and we work through access you grant and can revoke at any time.

Can you work inside our existing cloud account?

Yes. We work inside your account on AWS, Google Cloud, Azure or elsewhere, with scoped permissions, and billing and ownership stay with you.

How is production access controlled?

Access is restricted and not granted automatically to everyone on the project. Login is by SSH key behind a firewall, with a separate account per person, privileges scoped to responsibility, and removal when the need ends. Changes are traceable.

Are backups provided?

Yes for systems we host: daily encrypted backups to storage separate from the server, with a retention policy allowing recovery from more than one point in time. The schedule and retention are set in the support agreement.

Do you store payment card data?

No. Payment runs through a licensed gateway. Card numbers and security codes are never stored, never logged and never pass through our servers. We keep the transaction reference and status only.

Do you perform penetration testing?

Yes, as a separate engagement covering applications and infrastructure. It is not automatically included in every project and we do not claim otherwise. Baseline functional and security testing is part of the development cycle itself.

How are incidents handled?

We stop the damage first, triage the impact, fix the root cause, verify that service and data are intact, document what happened and why it was possible, then put a corrective action in place so it does not recur.

Do you support applications after launch?

Yes, under a monthly managed-support agreement covering monitoring, security updates, backups and incident response. This is an established line of work for us, not a sideline.

Can you take over or migrate an existing application built by someone else?

Yes. We start with a technical review of the code, infrastructure and security posture, and give you a written assessment before committing to any development. Sometimes the recommendation is not to rebuild.

What exactly do we receive at final delivery?

The complete source code with its revision history, editable design files, every credential and account registered for the project, app signing keys, and operating documentation. Ownership transfers to you contractually on full payment, so any competent team could take the system over after us without needing our permission.

Next step

A specific question before contracting?

If you have a specific security or operational requirement, or a vendor assessment form you want us to complete, send it and we will answer point by point on what we do and do not commit to. A "no" now is cheaper for you than finding out after signing.

Contact us Company facts →