Security practices
Application Security
How WebCastle builds, reviews, tests and deploys software — code review, environment separation, dependency handling, secrets and vulnerability management.
At a glance
- All code in version control; peer review before changes are merged.
- Development, staging and production are separated environments.
- Secrets held in environment configuration, not in source control.
- Automated scanning and a written SDLC standard are still being established.
Overview
WebCastle builds web and mobile applications for customers. Application security therefore has two sides: the security of the software WebCastle writes and hands over, and the security of the process used to write it. Both are described here.
The process rests on a small number of practices that are consistently applied. All code lives in version control with access limited to the assigned team. Changes are peer reviewed before they are merged. Development, staging and production are separate, and production deployment is carried out by a limited group of technical personnel. Credentials are supplied through environment configuration rather than committed alongside code.
What WebCastle does not yet have is the formal layer around those practices: an approved secure development lifecycle document, a written secure coding standard, automated scanning in the build pipeline, and independent security testing. Those are stated as in progress, developing or under evaluation below rather than implied. Where a customer requires a specific control — a defined test regime, a particular authentication model, or independent testing before go-live — it can be agreed as part of the engagement scope.
How a change reaches production
The path a code change follows, and the security checkpoints along it.
Requirements and design
ScopingSecurity requirements are captured alongside functional ones: who the users are, what roles exist, what data the application will hold, and any regulatory or contractual constraint the customer brings. Data handling expectations are agreed here rather than discovered at go-live.
Implementation
DevelopmentEngineers work in a development environment against non-production data. Framework-provided mechanisms are preferred over bespoke implementations for authentication, session handling, data access and output encoding.
Peer review
Before mergeAnother engineer reviews the change before it is merged. Review covers correctness and maintainability, and looks for the common defects: unvalidated input, missing authorisation checks, credentials in code, and unsafe data access patterns.
Testing and acceptance
StagingChanges are deployed to a staging environment that mirrors production configuration. Functional and regression testing is performed by the delivery team, and the customer performs acceptance testing where the engagement includes it.
Production deployment
ReleaseDeployment to production is performed by a limited number of technical personnel. Configuration and secrets are supplied by the environment rather than the release artefact, and the release is verified after deployment.
Maintenance and patching
OngoingApplications under a support arrangement receive framework and dependency updates through the same review and release path. Applications without an active support arrangement are patched on request; WebCastle recommends that customers keep a maintenance arrangement in place for this reason.
Application security controls
Status values are deliberate. "Developing" means the practice is applied by engineers but is not yet written down as a standard the whole company is held to.
Peer code review
EstablishedChanges are reviewed by another engineer before they are merged. Review is a routine part of the development workflow rather than an exception for sensitive changes.
- Review covers correctness, maintainability and obvious security defects such as unvalidated input or exposed credentials.
- Reviewers are engineers assigned to the same project, typically a senior engineer or technical lead.
- A written review checklist covering security-specific criteria is being developed.
Source control and repository access
EstablishedAll source code is held in Git. Repositories are private and access is restricted to the team members assigned to the project. History is retained, so every change is attributable to an author.
- Customer code is separated by repository.
- Repository accounts require multi-factor authentication.
Environment separation
EstablishedDevelopment, staging and production are separate environments with separate configuration and credentials. Production data is not copied into development environments as a matter of routine.
- Credentials valid in a lower environment do not grant access to production.
- Where realistic test data is needed, WebCastle uses generated or reduced datasets and agrees any exception with the customer.
Encryption in transit
EstablishedHTTPS is used across WebCastle-managed web and API endpoints, with certificates managed through the hosting platform. Plain HTTP requests are redirected.
Secure development lifecycle
OperatingSecurity considerations are raised at design and enforced at review, but WebCastle does not yet have an approved written SDLC document that a customer can be handed. That document is being drafted.
- Security requirements are captured with functional requirements during scoping.
- A documented set of gates that every release must pass is the next step.
Dependency management
OperatingThird-party libraries and frameworks are pinned in the project manifest and updated during active development. WebCastle is establishing a consistent approach to tracking advisories for dependencies in applications that are live but no longer under active development.
- Dependencies are chosen from actively maintained projects at the point a stack is selected.
- Updates are applied at project milestones and when a relevant advisory is identified.
- A per-project component inventory that supports advisory matching is being built.
Secrets management
OperatingApplication credentials, API keys and connection strings are held in environment configuration rather than committed to source control. WebCastle is standardising on cloud provider managed secret storage across all projects.
- Secrets are supplied to applications at deploy time through environment configuration.
- Historical repositories are being reviewed so that any credential committed in the past is rotated and removed from active use.
Vulnerability management
OperatingReported and discovered vulnerabilities are triaged by the technical lead for the affected application and fixed through the normal change process. Severity-based response targets are being formalized.
- Issues affecting production are prioritised over planned work.
- External reports are handled through the vulnerability disclosure process.
Authentication in delivered applications
OperatingApplications use established framework or identity-provider authentication rather than bespoke implementations. Passwords are stored using the hashing functions provided by the framework, never in reversible form.
- Session handling, expiry and logout behaviour follow framework defaults unless the customer specifies otherwise.
- Multi-factor authentication and single sign-on are implemented where the customer requires them as part of scope.
- A default authentication pattern applied across new projects is being agreed.
Authorization and access enforcement
OperatingAuthorization is enforced server-side on every request rather than by hiding interface elements. Role definitions are agreed with the customer during design.
- Object-level checks are applied so that a valid session cannot reach another user’s records by changing an identifier.
- Consistent enforcement patterns across all projects are being documented so that review has something explicit to check against.
Input validation and output handling
In practiceInput is validated server-side and database access uses parameterised queries or the framework data layer. Output encoding relies on the templating defaults of the framework in use. A written standard covering both is being developed.
- File uploads are constrained by type and size and are stored outside the application root.
- Validation rules are defined per endpoint during implementation and confirmed at review.
Automated security testing
Under EvaluationWebCastle is assessing automated dependency and code scanning in the build pipeline. No scanning tooling is in place as an established, enforced capability today, and security defects are currently caught by review and manual testing.
Environment separation
Each project runs across separate environments with distinct configuration, credentials and access.
| Environment | Purpose | Data | Access |
|---|---|---|---|
| Development | Feature implementation and local integration | Synthetic or generated test data | The assigned delivery team |
| Staging | Integration testing, regression testing and customer acceptance | Test data; production data only where the customer has approved it | The delivery team and nominated customer testers |
| Production | Live service to end users | Live customer and end-user data | A limited number of technical personnel |
Where a customer requires that production data never leaves the production environment, WebCastle works from generated datasets throughout. Any exception is agreed in writing with the customer.
Controls in delivered applications
The controls WebCastle applies inside the applications it builds. Specific requirements can be extended in the engagement scope.
API security
APIs require authentication on every endpoint that returns or modifies data, and enforce the same authorisation rules as the interface. Transport is HTTPS. Rate limiting and request throttling are applied where an API is publicly exposed, and CORS is restricted to the origins the application needs.
Input validation
Input is validated server-side even where client-side validation exists. Database access uses parameterised queries or the framework data layer rather than string-built statements. Uploaded files are constrained by type and size and stored outside the application root.
Session handling
Sessions use framework-provided mechanisms with secure and HTTP-only cookie attributes on HTTPS deployments. Session expiry and logout behaviour follow framework defaults unless the customer specifies a stricter requirement.
Error handling
Production applications return generic error responses to users. Stack traces, framework debug pages, database errors and internal paths are not exposed. Debug modes are disabled as part of production configuration.
Application logging
Applications log authentication events, errors and significant actions. Log content is intended to exclude passwords, tokens and payment data. WebCastle is standardising what is logged, and how long it is kept, across projects rather than leaving it to each application.
Configuration and secrets
Credentials, keys and connection strings are supplied through environment configuration at deploy time. Configuration files containing secrets are excluded from version control, and the standard approach is moving to cloud provider managed secret storage.
Third-party components
Most application risk arrives through dependencies. This is WebCastle’s current position on them.
- Selection
- Frameworks and libraries are chosen from actively maintained projects with an established release history. Abandoned components are avoided at the point a stack is selected.
- Updates
- Applied at project milestones and when a relevant advisory is identified. WebCastle does not publish a fixed update interval, because cadence is set by the support arrangement in place for each application.
- Advisory tracking
- Advisory monitoring is currently manual and led by the technical lead for each stack. Automated alerting on dependency advisories is being evaluated.
- End-of-life components
- Where an application depends on a framework version approaching end of support, WebCastle raises the upgrade with the customer as a scoped piece of work rather than allowing it to lapse silently.
Security testing and assurance
Security defects are currently found through peer review, manual testing during the delivery cycle, and reports received through the vulnerability disclosure process. WebCastle does not operate automated static or dynamic analysis tooling as an established capability, and does not commission formal third-party penetration testing of its delivered applications. Both are being assessed rather than claimed.
Customers who require independent assurance can arrange it. WebCastle supports customer-commissioned penetration testing of an application it has built, including scheduling a test window, providing test accounts, and remediating findings through the normal change process. Where testing is required before go-live, it is best agreed at scoping so that remediation time is built into the plan.
The next steps are dependency and code scanning integrated into the build pipeline, and a written secure coding standard that gives review an explicit set of criteria. Progress on both is reflected in the control statuses above and will be updated on this page as it lands.