Sixfields Software builds operational software for field service businesses. Our clients depend on it daily — jobs dispatched, engineers tracked, sign-offs captured. That operational trust has to be earned at every layer of the stack, not bolted on at the end.
This page explains how we approach security across the Sixfields Core platform and every product built on top of it.
Sixfields Core
Rather than building each client product from scratch, we developed Sixfields Core — a hardened application platform that serves as the foundation for all bespoke software we deliver. Think of it as the engine under the bonnet: every client-facing product inherits its architecture, security model, and data handling patterns from Core.
This approach means security improvements, patches, and hardening measures made to Core propagate immediately across every product built on it. A vulnerability fixed once is fixed everywhere.
Every feature is evaluated for security implications before it ships. Security is a constraint, not an afterthought.
Users, processes, and services only get access to exactly what they need — nothing more.
Multiple independent security layers, so a failure in one doesn't expose the system.
No component trusts another implicitly. Every request is authenticated and validated regardless of origin.
Build it. Break it.
We don't just build software and hope for the best. After development, we actively attempt to break what we've built — testing Core and client applications against the attack vectors most commonly used in the real world.
Our internal security review process covers:
- Attempting to bypass authentication mechanisms
- Session hijacking and fixation attacks
- SQL injection, blind injection, and ORM bypass attempts
- Cross-site scripting (XSS) — reflected, stored, and DOM-based
- Cross-site request forgery (CSRF) token bypass attempts
- Forced browsing and broken access control testing
- IP spoofing and header manipulation
- Rate limiting and brute-force resistance
- Insecure direct object reference (IDOR) testing
- File upload abuse and path traversal
If we find something, we fix it before the feature ships. This isn't a checkbox exercise — it's how we build confidence in the platform.
Transport security
All traffic to and from Sixfields Core is encrypted in transit. We enforce HTTPS across every endpoint — there is no HTTP fallback. Connections are upgraded automatically and HTTP requests are permanently redirected.
- TLS 1.2 minimum; TLS 1.3 preferred
- Weak cipher suites and legacy protocols (SSLv3, TLS 1.0, TLS 1.1) are disabled
- HTTP Strict Transport Security (HSTS) headers enforced
- Certificates managed and auto-renewed; expiry monitored
- Secure and HttpOnly flags set on all cookies
Authentication
Access to any Sixfields-powered application requires authentication. Passwords are never stored in plain text or with reversible encryption.
- Passwords hashed using bcrypt with an appropriate cost factor
- Login attempts rate-limited and monitored for brute-force patterns
- Account lockout after repeated failed attempts
- Password strength requirements enforced at registration
- Secure password reset flow using time-limited, single-use tokens sent to verified email addresses
- Multi-factor authentication (MFA) available for admin accounts
- Authentication tokens are cryptographically random and server-validated on every request
Session security
Sessions are one of the most common attack surfaces in web applications. We treat session management as a first-class security concern.
- Sessions use cryptographically random, long-entropy identifiers
- Session IDs are regenerated on login to prevent session fixation attacks
- Sessions are invalidated immediately on logout — server-side, not just client-side
- Idle session timeout enforced; sessions expire after a configurable period of inactivity
- Concurrent session controls available — new logins can optionally invalidate existing sessions
- Session data is never stored in client-accessible cookies; only the session ID is transmitted
- Session cookies are scoped to the correct domain and path, with SameSite protections applied
- Suspicious session behaviour (e.g. IP change mid-session) triggers re-authentication
Injection & XSS protection
Injection attacks — SQL, command, LDAP, and others — remain among the most exploited vulnerability classes. We build defensively against them at every layer.
SQL injection
- All database queries use parameterised statements or a query builder that enforces parameterisation — raw string interpolation into queries is prohibited
- Database accounts used by the application have the minimum permissions required — no DROP, no schema changes
- Query errors are caught and logged internally; stack traces are never exposed to the client
Cross-site scripting (XSS)
- All user-supplied input is escaped before rendering in HTML, JavaScript, or URL contexts
- Content Security Policy (CSP) headers restrict which scripts, styles, and resources the browser will execute
- Rich text input is sanitised through an allowlist-based parser — no arbitrary HTML is ever trusted
- DOM-based XSS mitigated by avoiding dangerous JavaScript patterns (innerHTML, document.write, eval)
- X-Content-Type-Options and X-Frame-Options headers set to prevent MIME sniffing and clickjacking
CSRF protection
Cross-site request forgery attacks trick authenticated users into unknowingly submitting malicious requests. Sixfields Core defends against this at the framework level.
- Every state-changing request (POST, PUT, PATCH, DELETE) requires a valid, session-bound CSRF token
- Tokens are cryptographically random, per-session, and verified server-side on every submission
- SameSite cookie attributes provide an additional browser-level CSRF barrier
- API endpoints use token-based authentication rather than session cookies, which are inherently CSRF-resistant
- Referer and Origin headers are validated on sensitive operations as a secondary check
IP & access control
Access to sensitive areas of the platform can be restricted at the network level, not just the application level.
- Admin and management interfaces can be IP-allowlisted, restricting access to known office or VPN addresses
- Requests from known malicious IP ranges are blocked at the server level
- Rate limiting applied per IP address to slow brute-force, credential stuffing, and scraping attempts
- Repeated failed authentication from a single IP triggers temporary blocks and alerts
- Reverse proxy and firewall rules prevent direct access to application servers
- Internal services are not exposed to the public internet; access is via private networking only
- Client applications can be configured to restrict logins to specific IP ranges where required by the client
Data security
Client data is treated as sensitive by default, regardless of its apparent sensitivity.
- Data at rest is stored on encrypted volumes
- Sensitive fields (tokens, secrets, API keys) are encrypted at the application level, not just the storage level
- Client data is logically isolated — no cross-client data leakage is possible by design
- Backups are encrypted, tested regularly, and stored separately from primary data
- Data exports and reports include only the data the requesting user is authorised to see, validated server-side
- File uploads are validated for type, scanned for malicious content, and stored outside the web root
- Personally identifiable information is handled in line with our Privacy Policy and UK GDPR obligations
Infrastructure
The platform is hosted on dedicated infrastructure in the United Kingdom, managed by eUKHost — a UK-based provider with ISO 27001 certification and UK data residency guarantees.
- Server OS and software packages kept up to date; security patches applied promptly
- Unnecessary services, ports, and modules disabled — attack surface minimised
- SSH access restricted to key-based authentication; password-based SSH login disabled
- Fail2ban and equivalent tools monitor for and automatically block suspicious access patterns
- Application error logs and access logs monitored; anomalies flagged for review
- Server-level firewall (iptables/UFW) in place; only required ports exposed
- Automated daily backups with point-in-time recovery capability
- Uptime and performance monitoring with alerting for unexpected behaviour
Responsible disclosure
We welcome security researchers and users who identify potential vulnerabilities in our platform or client applications. If you believe you have found a security issue, please tell us before disclosing it publicly — we will investigate promptly and work to resolve it.
We ask that you:
- Do not access, modify, or delete data that does not belong to you
- Do not disrupt live services or other users
- Give us reasonable time to investigate and respond before any public disclosure
We will not pursue legal action against researchers who act in good faith under these guidelines. We genuinely appreciate responsible disclosure — it makes the platform better for everyone.