This security review is adapted from a real document written and presented to management. Company details, report metadata, domains, screenshots, and internal references have been anonymized to reduce exposure and legal risk. The substance of the findings and recommendations is unchanged.
Overview
Service Organization Control Type 2, or SOC 2, is a compliance framework that helps technology and service organizations protect data and systems from cyber attacks and unauthorized access. The framework is based on five Trust Services Criteria:
- Security
- Availability
- Processing integrity
- Confidentiality
- Privacy
SOC 2 is different from some other compliance standards because it is not simply a fixed checklist of controls to implement. It takes a risk-based approach and describes broader business and security outcomes that an organization needs to address.
Because the SOC 2 criteria are broad, each organization may satisfy them differently depending on its systems, risks, data, customers, and internal processes. The goal is to create security controls and practices that work for the business while satisfying the required criteria.
For this analysis, representative third-party security findings were mapped to recommended fixes, testing steps, and future development guidance.
Company names, reviewer names, report dates, ticket numbers, and internal tracking references have been removed or generalized.
High Severity
Impact scores are based on the third-party security report and appear to be in line with common industry severity ratings.
The original report source, reviewer name, ticket numbers, screenshots, and internal references have been removed for confidentiality.
Secure Cookies
Secure cookies were not enabled for the application session cookie. This was marked as a high-impact issue because session cookies should only be transmitted over secure HTTPS connections.
Recommendation
Update the application or server configuration so the session cookie includes the proper secure settings.
Testing Resolution
After secure session cookies are enabled, the Set-Cookie header should include both Secure and HttpOnly. This can be verified with Postman, browser developer tools, or another HTTP header inspection tool.
Example expected behavior:
Set-Cookie: [session-cookie-name]=[value]; path=/; Secure; HttpOnlyThe original document included screenshots with highlighted response headers. They are not shown here because they exposed application-specific cookie names and internal test details.
Object Storage ACLs
The site uses object storage to store files. If access control lists are not configured correctly, files may be accessible without a valid token, password, or authenticated request.
Recommendation
Review the object storage access controls and confirm that private files are not publicly accessible. Storage-level permissions should be checked directly in the cloud provider console or equivalent management tool.
Testing Resolution
There may not be a single automated testing tool that fully validates this item. The storage configuration should be reviewed directly, and sample private files should be tested to confirm they cannot be accessed without proper authorization.
Once the ACLs are confirmed, the issue can be marked as resolved in the security review process.
Cloud provider names, ticket numbers, reviewer references, and report-specific instructions have been removed for confidentiality.
Low Severity
Visible Browser Logs
The site emits visible browser logs. The risk is that browser logs may expose sensitive information to unauthorized parties. Logs can sometimes disclose credentials, personally identifiable information, internal system details, error messages, or other confidential data.
Even when no sensitive data is present, visible logs can give attackers more information about the website's internal structure or possible weaknesses.
Recommendation
For JavaScript files, remove development logging such as console.log, console.error, and console.warn from production builds.
This can be handled through the build tooling or CI/CD pipeline. Since the impact is low, it may be more efficient to include this work as part of a larger frontend upgrade rather than handling it as a standalone change.
Testing Resolution
ZAP or another penetration testing tool can check JavaScript files for visible logging statements in production assets.
Specific framework upgrade references and internal ticket numbers have been removed for confidentiality.
Content Security Policy
The Content Security Policy contains broad directives. When a CSP is configured with overly broad settings, it can allow the browser to load resources from too many sources, including potentially unsafe domains.
This weakens the protection CSP is meant to provide against Cross-Site Scripting attacks and other injected content risks.
Recommendation
Add appropriate Content-Security-Policy headers to the web server, application server, or load balancer, depending on where headers are managed in the infrastructure.
Testing Resolution
Headers can be tested with browser developer tools, Postman, security scanning tools, or CSP validation tools. The policy should be reviewed to confirm that directives are specific enough for production use and do not allow unnecessarily broad sources.
Ticket numbers and report-specific references have been removed for confidentiality.
HSTS Missing
HTTP Strict Transport Security was not implemented. Without HSTS, users may be more exposed to protocol downgrade attacks, cookie hijacking, or man-in-the-middle attacks.
HSTS tells browsers to enforce secure HTTPS connections, which helps protect the confidentiality and integrity of communication between users and the website.
Recommendation
Add the appropriate Strict-Transport-Security header to the web server, application server, or load balancer, depending on where headers are managed.
Testing Resolution
Testing can be done with an HTTP header inspection tool, browser developer tools, Postman, or an HSTS validation service.
The original document included a company-specific domain validation URL. It has been removed for confidentiality.
Embedding of Malicious Content
The site may be vulnerable to clickjacking if pages can be embedded inside iframes on other domains without restriction. Clickjacking can trick users into interacting with hidden or altered content.
This can lead to unauthorized actions, data exposure, or user confusion when a legitimate page is embedded inside a malicious page.
Recommendation
Add or update the appropriate frame protection headers. If an older header is already present but deprecated, replace or supplement it with the recommended modern Content Security Policy directive.
Testing Resolution
Testing can be done with Postman, browser developer tools, or another HTTP header inspection tool to confirm that the expected frame protection header or CSP directive is present.
Internal ticket numbers and implementation-specific references have been removed for confidentiality.
X-Content-Type-Options Best Practices
The site did not fully follow best practices for the X-Content-Type-Options header. Without this header set correctly, browsers may attempt MIME type sniffing and interpret content differently than intended.
This can create security risk if a browser executes content as a different type than the server intended, potentially increasing exposure to Cross-Site Scripting or other content handling issues.
Recommendation
Add the X-Content-Type-Options header with the appropriate value at the web server, application server, or load balancer.
Testing Resolution
Testing can be done by checking response headers with Postman, browser developer tools, or another HTTP header tool.
Internal ticket references have been removed for confidentiality.
Unsafe Implementation of Subresource Integrity
Externally loaded resources, such as scripts and stylesheets, may lack integrity verification. Without Subresource Integrity, third-party files can be tampered with without the browser being able to detect that the file has changed.
This can create a path for attackers to inject malicious scripts or modified assets into the page.
Recommendation
Review externally loaded scripts and stylesheets and add Subresource Integrity where appropriate. For resources that change frequently or are controlled through a build process, confirm whether SRI is practical before applying it.
Testing Resolution
Testing can be done with ZAP, an SRI checking tool, or a manual review of externally loaded assets.
Internal ticket references have been removed for confidentiality.
Content Security Policy 3 Missing
The report also identified a missing or incomplete Content Security Policy finding. This appears to overlap with the earlier CSP finding.
Without a strong CSP, a web application may be more exposed to Cross-Site Scripting, clickjacking, unsafe resource loading, and other injected content risks.
Recommendation
Treat this as part of the broader Content Security Policy remediation unless further analysis confirms that it is a separate issue.
Testing Resolution
Testing can be done with Postman, browser developer tools, CSP validation tools, or another header inspection tool.
Duplicate ticket references and report-specific details have been removed for confidentiality.
Site Fails to Load Page Components
Some page components may fail to load, such as images, stylesheets, scripts, or other assets. This can result in broken layouts, incomplete features, reduced interactivity, and a poor user experience.
While this finding is lower severity from a security standpoint, it can still affect trust, usability, and the perceived reliability of the application.
Recommendation
Further analysis is required to identify which assets or components are failing to load. This should include reviewing application logs, asset delivery paths, CDN behavior where applicable, and frontend error handling.
The application should also be reviewed for graceful handling when non-critical page components fail to load.
Testing Resolution
Testing recommendations should be finalized once the exact failing components are identified.
Specific infrastructure references and internal system names have been removed for confidentiality.
Long-Term Plan
Once the findings are implemented, additional documentation and best practice instructions should be provided to the development team or SRE team as needed.
A quarterly penetration test and follow-up analysis are recommended to help maintain compliance and identify new issues before they become larger problems.
The exact schedule and requirements can be defined later, after more is known about the current setup, the effectiveness of the recommended fixes, and any remaining issues discovered during the next security review or penetration test.
Appendix
Official SOC 2 Organization Documents
SOC 2 Compliance References
- University of Tulsa: What Is SOC 2 Compliance?
- Varonis: SOC 2 Compliance
- AuditBoard: SOC 2 Framework Guide
Internal report links, company-specific references, and ticket numbers have been removed for confidentiality.