A practical overview of the learning, methods, tools, and research areas Security Cyber is built around. If something here matches a real requirement, the contact page is open for a scoped conversation.
These are the areas of practice and methodology behind Security Cyber. They are presented as scope starters, not fixed packages; any real work begins with written authorisation and a clear boundary.
Manual web application review informed by OWASP Top 10, PortSwigger Web Academy practice, TryHackMe, and Hack The Box labs. The emphasis is on clear scope, careful evidence, and issues that can be explained without inflating risk.
Lab-grounded adversary thinking mapped to MITRE ATT&CK. The useful output is not theatrics; it is understanding likely external exposure, plausible access paths, and where defensive attention should go first.
REST and GraphQL review aligned to the OWASP API Security Top 10. Typical discussion points include object-level authorisation, mass assignment, rate limiting, JWT handling, endpoint inventory, and function-level access control.
Reconnaissance and open-source intelligence used to understand what is already visible from the outside. The value is a calmer view of exposed domains, metadata, cloud traces, technology signals, and account footprint.
Clear reporting is treated as part of the craft, not an afterthought. Findings are written so a technical reader can reproduce them and a non-technical reader can understand priority, impact, and next steps.
Awareness support for small teams that need practical language around phishing, pretexting, MFA, suspicious links, and reporting routes. The goal is usable judgement, not fear-based training.
These frameworks shape the learning, lab work, write-ups, and any authorised project discussions. They keep the work structured without presenting Security Cyber as a large consultancy.
A practical reference for web application security testing. It gives structure for authentication, authorisation, input validation, session management, and business logic review.
owasp.org →The current reference point for API risk areas, including BFLA, unrestricted resource consumption, unsafe consumption patterns, and inventory problems.
owasp.org/API-Security →A recognised knowledge base for adversary tactics and techniques. Useful for mapping lab work, detection ideas, and realistic defensive thinking.
attack.mitre.org →Every finding is scored against Common Vulnerability Scoring System v3.1 — providing a consistent, numeric severity rating based on attack vector, complexity, privileges required, user interaction, scope, and CIA impact.
first.org/cvss →A phase-based reference for authorised testing: pre-engagement, intelligence gathering, threat modelling, vulnerability analysis, exploitation, post-exploitation, and reporting.
pentest-standard.readthedocs.io →NIST's technical guide to information security testing and assessment. Used as a reference for engagement planning, rules of engagement design, and ensuring testing activities are properly scoped, authorised, and documented.
nist.gov →If a discussion turns into authorised work, the process stays simple: define the boundary, agree permission, do only what was approved, then document the result clearly.
A short email thread or call to understand the context, target ownership, timeline, and what kind of help is actually useful.
Written scope definition and Rules of Engagement document. Confidentiality can be discussed where needed. Nothing begins until both parties sign off.
Only the agreed scope is touched. Manual review comes first; tools support the process rather than replacing judgement.
Findings, evidence, reproduction notes, limitations, and next steps are written plainly so the result is usable.
A practical toolkit used in lab work, write-ups, and authorised scope discussions. Tool use is presented through reproducible notes, evidence, and clear limitations.
// All tools are used only within agreed scope on authorised targets. Exploitation tools are used solely in controlled lab environments or with explicit written permission on defined targets.
Certifications and labs are shown here for context. They explain the current learning base, what has been practised, and where the next steps are.
Introductory cyber security foundation covering common threats, basic security principles, safe working practice, and the language needed for further SOC and analyst training.
TryHackMe Web Fundamentals training covering how web applications work, HTTP basics, authentication concepts, common web weaknesses, and the foundations required for OWASP Top 10 testing.
Jr Penetration Tester training/certificate focused on beginner-to-intermediate offensive security skills: reconnaissance, enumeration, exploitation basics, web vulnerabilities, and reporting discipline.
ISC2 Certified in Cybersecurity (CC), completed 2026. Certificate evidence also lists completed CC domain training across security principles, incident response and BCDR, access control, network security, and security operations.
Supplied CV evidence lists 149+ TryHackMe rooms, 26 badges, top 3% platform ranking, and Hack The Box practice covering SOC alert triage, log analysis, phishing investigations, malware sandboxing, OWASP Top 10 testing, and network enumeration.
Active Hack The Box lab practice used to reinforce enumeration, Linux fundamentals, web application vulnerabilities, and real-world problem solving in controlled environments.
// Certification claims on this site are limited to supplied CV, certificate evidence, or public profile links. Future targets are not listed as credentials.
// If your requirement is beyond current scope, that is stated upfront. Referrals to appropriate firms may be suggested for work outside these bounds.
Responsible disclosures and verified research — real results, honestly presented. Every finding includes context of where and how it was discovered.
Security Cyber is a small student-founded platform and portfolio operated by Charlie Collins. It documents learning, labs, tooling, write-ups, responsible research, and scoped project discussions.
Yes — always, without exception. No testing starts until a clear written scope and Rules of Engagement document is agreed and signed by both parties. This protects both sides and keeps the engagement legally and ethically clean.
That depends on scope. It may be a short written note, a structured PDF, reproduction steps, screenshots, CVSS scoring, remediation guidance, or a responsible disclosure write-up.
Initial replies are usually quick. If the work is authorised and scoped, timelines are agreed before anything begins rather than guessed upfront.
The output still documents the agreed scope, checks performed, limitations, and any useful hardening notes. Honest confirmation that specific attack paths were not reproduced is valid when the scope supports it.
Where a finding is in scope, a follow-up check can be agreed. The aim is to confirm the issue is fixed, not to expand into unapproved testing.
They make the current skill set visible without overselling it. They also help people understand what kinds of conversations are appropriate before sending a message.
If something here lines up with a real project, disclosure, or collaboration, send the context and keep the scope clear from the start.