Professional Penetrationtests according to international Standards

Professional security checks of your Web Applications, API Interfaces and Network Infrastructure. We simulate a professional hacker attack to identify potential vulnerabilities and protect your systems from attackers.

Can unauthorized persons invade your systems?

Are your applications and services adequately protected from attackers?

Reputational damage

Hacker attacks can damage your company image and threaten your very existence, as they cause a loss of public confidence.

Data loss

Once your data are in the wrong hands, they are often misused and resold to criminals. This scenario is a nightmare for every one of your customers.


The EU Data Protection Basic Regulation (EU-DSGVO), which came into force on 25 May 2018, means that the loss of customer data can result in penalties and associated financial losses.


Hacker attacks, in particular malware attacks, can affect your business operations or even bring them to a standstill.


Web penetration tests are planned, performed and evaluated by our specially trained analysts according to recognized standards.


Web Applications Tested


Vulnerabilities Discovered


Bug Bounties
Benefit from the many years of experience of our analysts.
  • Our analysts have extensive academic training and many years of experience in identifying and resolving vulnerabilities of all kinds.
  • Through regular training and further education, we ensure that new tools and techniques can be used as quickly as possible.
  • We are constantly developing our tools and processes in order to provide our customers with the best possible results.
  • Extensive research ensures that even daily updated vulnerabilities can be identified.
We carry out safety analyses on the basis of recognised standards and guidelines.
  • We audit web applications using the OWASP Testing Guide. Our tools and procedures are able to identify the vulnerability categories of the OWASP Top 10 in the best possible way.
  • The testing of mobile apps is performed according to the categorization of the MASVS (Mobile Application Security Verification Standard)
  • Our processes are compliant with the practice guidelines for penetration tests of the Federal Office for Information Security (BSI) adapted.

Selected Customers



Penetration tests carried out by us are an agile process and are carried out in close consultation with the customer.


The preparation of the pentest takes place in the context of a kick-off meeting with the technical and organizational responsible persons of your company. The framework conditions to be tested are specified, necessary user accounts and access routes are agreed, contact persons and escalation routes are defined and the pentest is discussed in detail together.


Our analysts try to collect as much information as possible. Based on this information, analysis strategies are developed to identify possible attack vectors. These attack vectors are then examined for vulnerabilities in extensive tests.


In this phase, an attempt is made to actively exploit the identified vulnerabilities in order to gain access to the target systems. Depending on the service or technical environment, our pentester writes new exploits or uses existing ones. Potential vulnerabilities can turn out to be false positives. Only verified vulnerabilities are included in the final report and classified according to their criticality.


You will receive a comprehensive final report consisting of a Management Summary and a Technical Report. The criticality of the weak points and recommendations for action are described in detail.

Remediation (Optional)

In this phase, the identified weak points are eliminated by your company. If required, you will be supported by our experienced security engineers.

Nachprüfung (Optional)

After the remediation you have the opportunity to have us carry out a follow-up check. Here we check the effectiveness of your measures and adjust the result report.

Abschlussgespräch (Optional)

In this final discussion, all critical points in the results report are discussed and all final questions clarified.

Final Report

We have developed a comprehensive reporting format that provides optimal insight into our work and its results.

  • Web penetration tests are performed and evaluated according to the OWASP Testing Guide.
  • Our detailed reporting format not only provides information about which vulnerabilities were identified during the penetration test, but also which attack vectors were checked. This allows you to understand our work in an optimal way.
  • The final report is created individually and delivered both as a classical PDF document and in a special HTML format. In the dynamic HTML format, content and vulnerability findings can be filtered, sorted and exported to other formats.
  • In a joint final meeting, we will discuss the details of the report with you and, if necessary, support you in eliminating the identified weaknesses.


The following section describes our test modules. Basically, the longer our analysts examine your web application, the more meaningful the results will be. If you have special requirements, we will be happy to make you an individual offer.

We cover the entire app spectrum! Our analysts are familiar with native, web, hybrid and progressive web apps.
Architecture, design and threat analysis

  • API endpoint security
  • Architecture overview of all dependencies
  • Identification of all sensitive data
  • Scope of functions identification
  • Threat analysis of API endpoints
  • Safety functions in central components
  • Cryptographic key management
  • Enforce app updates
  • Security in the software development cycle
Data storage and data protection

  • Storage mechanisms
  • App Container Security
  • Logfiles
  • In-App data security
  • Keyboard cache
  • Interprocess communication
  • Sensitive data
  • Operating system controlled backup
  • Background mode
  • Memory area
  • Equipment protection guideline area
  • Security Best Practice Recommendations

  • Hard-coded keys
  • Cryptographic primitive
  • Best practice guidelines
  • Obsolete algorithms
  • Reuse of cryptography
  • Random number generator
Authentication and Session Management

  • Authentication
  • Session management
  • Token-based authentication
  • API endpoint
  • Password policy
  • Login attempts
  • Access token
  • Biometric authentication
  • 2. authentication factor
  • Sensitive transactions
  • Login procedures
Network communication

  • TLS encryption
  • Best Practices
  • X.509-certificate
  • Certificate store
  • Communication channels
  • Communication links
Platform interaction

  • App Permissions
  • Interprocess communication with external sources
  • Debugging symbols
  • App-own URL schemas
  • App-own interprocess communication
  • JavaScript WebViews
  • WebView Log Handler
  • Javascript from external sources
  • Object serialization
Code quality and build settings

  • App signature
  • Release settings
  • Binary files
  • App logs
  • Third party libraries and frameworks
  • Error handling
  • Security features
  • Offered security functions of the development environment
Manipulation Security - Dynamic Analysis

  • Rooted device
  • Debugging
  • App's own sandbox
  • Reverse-Engineering-Tools
  • Main memory area
  • Multi-layer mechanisms
  • Recognition mechanisms
  • Programmatic defensive measures
Manipulation security - Device binding

  • Device binding mechanism
Manipulation security - prevent traceability

  • File-level encryption
  • Obfuscation mechanism
Information Gathering

  • Search Engine Discovery and Reconnaissance
  • Webserver Fingerprinting
  • Webserver Metafiles
  • Application Enumeration
  • Comments and Metadata
  • Application Entrypoints
  • Executionpaths Mapping
  • Framework Fingerprinting
  • Application Fingerprinting
  • Application Architecture

  • Network/Infrastructure Configuration
  • Application Platform Configuration
  • File Extensions Handling
  • Old, Backup and Unreferenced Files
  • Admin Interfaces
  • HTTP Methods
  • HTTP Strict Transport Security
  • RIA Cross Domain Policy
  • File Permissions
  • Subdomain Takeover
Session Management

  • Session Management Schema Bypassing
  • Cookies Attributes
  • Session Fixation
  • Session Variables
  • Cross Site Request Forgery
  • Logout Functionality
  • Session Timeout
  • Session Puzzling
Error Handling

  • Error Codes
  • Stack Traces
Identity Management

  • Role Definitions
  • User Registration Process
  • Account Provisioning Process
  • Account Enumeration and Guessable User Accounts
  • Username Policy

  • Credentials Over Encrypted Channel
  • Default Credentials
  • Weak Lock-Out Mechanism
  • Authentication Schema Bypassing
  • Remember Password Functionality
  • Browser Cache
  • Password Policy
  • Security Questions
  • Password Change or Reset
  • Authentication in Alternative Channel

  • Directory Traversal/File Inclusion
  • Authorization Schema Bypassing
  • Privilege Escalation
  • Insecure Direct Object References
Input Validation

  • Reflected Cross Site Scripting
  • Stored Cross Site Scripting
  • HTTP Verb Tampering
  • HTTP Parameter Pollution
  • SQL Injection
  • LDAP Injection
  • ORM Injection
  • XML Injection
  • SSI Injection
  • XPath Injection
  • IMAP/SMTP Injection
  • Code Injection
  • Command Injection
  • Buffer Overflow
  • Incubated Vulnerabilities
  • HTTP Splitting/Smuggling
  • HTTP Incoming Requests
  • Host Header Injection

  • Transport Layer Protection
  • Padding Oracle
  • Unencrypted Channels
  • Weak Encryption
Business Logic

  • Data Validation
  • Request Forgery
  • Integrity Checks
  • Process Timing
  • Usage Limits
  • Circumvention of Work Flows
  • Application Mis-use
  • Upload of Unexpected File Types
  • Upload of Malicious Files

  • DOM Based Cross Site Scripting
  • JavaScript Execution
  • HTML Injection
  • URL Redirect
  • CSS Injection
  • Resource Manipulation
  • Origin Resource Sharing
  • Cross Site Flashing
  • Clickjacking
  • WebSockets
  • Web Messaging
  • Local Storage

  • Generic Testing
  • Parameter Fuzzing
  • Insecure Direct Object References
  • Privilege escalation
  • (Token-Based) Authentication
  • JWT Brute Forcing

  • Outdated Software
  • Public Disclosed Vulnerabilities

  • Search Engine Discovery and Reconnaissance
  • Port-Scanning
  • Service Fingerprinting
  • Application Enumeration
  • Network Architecture

  • Outdated Software
  • Public Disclosed Vulnerabilities

  • Configuration
  • Cryptography


In the following we have compiled an overview of frequently asked questions. If you have any further questions, please do not hesitate to contact us.

  • How do the individual test types differ?

    The individual test types differ in scope and time required. Basically, the longer the test period, the more meaningful the results.

  • Can the safety analysis also be carried out on site?

    Security analyses are usually carried out remotely by us. If your application cannot be reached externally, our analysts will be happy to assist you in setting up remote access. If this is also not possible, our analysts will visit your company and carry out the security analysis on site. Please note that on-site tests are subject to additional costs and time restrictions.

  • What are the OWASP Top 10?

    The OWASP Top 10 project serves to identify and explain the most common vulnerabilities of web applications. It represents a broad consensus on the most critical security risks for web applications and thus increases the transparency and effectiveness of our work.

  • What is the OWASP Testing Guide?

    OWASP Testing Guide provides a test guide that defines procedures and techniques used to test the most common security vulnerabilities in applications. The guide has evolved into a de facto standard for performing security analysis of Web applications.

  • What does Black-, Grey- and Whitebox-process mean?

    In the whitebox process, our analysts have access to and knowledge of the development of the software (source code and any existing documentation). The Greybox method is a technique for testing the software product with partial knowledge of the internal functioning of an application. With the black box method, on the other hand, the testers have no access to and knowledge of the software.

  • What happens if no vulnerabilities can be identified during the security analysis?

    Despite thorough review, little or no vulnerabilities may be identified. Thanks to our comprehensive final report, however, they can still optimally understand our work.

  • Can safety analyses be performed at a certain interval or in the release cycle of the application?

    We offer you individual subscriptions and an attractive discount for regular customers. With these pricing models, your projects enjoy the highest priority.

  • How can weak points be identified and avoided during the development process?

    For an iterative review in the development process, turingpoint GmbH offers DevOps security consulting, for example.

  • What does security engineering mean?

    Our security engineers cover tools, processes and methods for the design, implementation and testing of secure IT system applications. Security engineering ensures that the specification is met under the intended security conditions.

  • Should backups of the target systems be made?

    Despite the fact that crashes or even data loss are very rare during our security analysis, we generally recommend that you create a backup of the target system.

  • Is login information required for the security analysis?

    If a backend or secured user areas are to be checked, exemplary logon data is required in order to be able to examine all application sections.

  • Can security analyses be carried out outside business hours?

    If your web application is under high load during our business hours (weekdays, 8-20 o'clock) or the reliability is not guaranteed during this period, it is also possible to carry out tests outside our business hours. Please note that we charge a surcharge in such cases.

  • What time period should be planned for a safety analysis?

    The time period to plan for our web pentests depends on the type of test you choose and the complexity of your web application. For our basic test we plan 1-2 working days, the standard test 1 week and the comprehensive test 2 weeks. In addition, our analysts need time to prepare the final report.

  • Are a lot of requests sent to our Websever?

    Our self-developed web application verification tools can generate high traffic on the target system. If our analysts or their IT team experience performance problems during the security analysis, we can throttle our software.

  • Can safety analyses also be carried out at short notice?

    Thanks to our flexible processes, we can also start your time-critical project at short notice.

  • How are vulnerabilities found in a security analysis?

    Our analysts use their many years of experience and tools, such as self-developed software, to find security problems in your web application.

  • Are vulnerabilities already reported during the security analysis?

    As part of the kick-off discussion, our analysts agree with you on a contact person to whom critical weak points can be reported during the security analysis.

  • Which tools are used for security analyses?

    We use common tools like OWASP ZAP, BurpSuite, SQLMap. However, our work is based on a self-developed software, which is constantly extended and improved by us.

  • Can confidential data of the target application be viewed during the security analysis?

    It cannot be avoided that confidential data can become visible during the security analysis. In principle, an NDA (Non-Disclosure Agreement) is to be agreed before the security analysis begins.

  • Are Denial of Service (DoS) attacks performed?

    In principle, our analysts do not carry out any Denial of Service (DoS) attacks. However, due to the high number of page views by our software, it can happen that our test is identified as a Denial of Service (DoS) attack.

  • Is there a default risk for the target systems?

    A risk of failure of the target system cannot be ruled out during a safety analysis. You should therefore have up-to-date backups and the responsible IT team should be available. If available, the test should be performed on a test or acceptance system.

  • How long does it take to prepare the final report?

    The preparation of the final report is part of our offer and takes about 2 additional days.

  • Why is the final report also delivered in HTML format?

    In our dynamic HTML format, content and vulnerability finds can be filtered, sorted and exported to other formats. This allows your IT team to process the finds more efficiently.

  • How can the work performed be reconstructed in a safety analysis?

    Our work can be optimally understood through our comprehensive final report. We document not only the findings, but also the actions of our analysts.

  • What is the procedure of a re-test?

    An optional re-test can take place once your IT team has resolved the previously identified vulnerabilities. This is not a full security analysis, but simply a re-testing of the previously identified security issues.

  • Are we supported in eliminating the safety analyses?

    In our comprehensive reporting format, our analysts document measures with which the identified security problems can be resolved. Should you require technical support, we will be happy to make you an individual offer for advice from our security engineers.

  • Can the final meeting also be held on site?

    The final meeting can be held in your company for a flat-rate travel allowance as part of a presentation.