Developed in 2012 and made open source in 2015 by Facebook, GraphQL (Graph Query Language) has been under the umbrella of the GraphQL Foundation since 2019.

GraphQL is a query language, i.e. a language used to access data in a database or any other information system, in the same way as SQL (Structured Query Language).

Authentication and, by extension, user identification are central to web applications.

These two mechanisms are used to manage rights and access (for example, between an administrator and a standard user), to partition data between different accounts, to identify different users, etc.

During a penetration test, we generally consider 3 test conditions: black, grey or white box.

These test conditions correspond to the levels of information provided to the pentesters in order to carry out a pentest on a specific target. While a white box pentest will consist of providing as much information as possible, during a black box penetration test, the pentesters will have no data on the test target.

When pentesting a web application, an API or an internal network, there are generally 3 approaches: black box, grey box and white box testing.

These approaches or test conditions correspond to different levels of information provided to the pentesters to identify potential vulnerabilities and weaknesses that could compromise the integrity of a target system.

What is Smishing?

You will no doubt be familiar with phishing, which consists of sending malicious emails to encourage people to perform sensitive actions, such as entering their credentials on a fake authentication page.

Smishing is very similar, except that the attacker does not send emails, but text messages, hence the name smishing. Essentially, smishing is nothing more and nothing less than SMS phishing.

With cybersecurity risks on the rise, it is becoming more and more obvious to carry out a penetration test (pentest) to reassure customers, partners and investors.

Moreover, for companies involved in a certification process (ISO 27001, SOC2, HDS, PCI-DSS, etc.), a penetration test is an imperative. And for others, it is an essential prerequisite for satisfying the pentesting report requests of their customers and prospects.

APIs are prime targets for attackers because of their exposure and critical nature, particularly in terms of handling sensitive data. To minimise the risk of security breaches, it is essential to implement robust security measures, understand the types of attack and assess their potential impact.

There are several ways of assessing the security of an API. In this article, we present the “offensive” approach, which we believe to be the most effective: API penetration testing (or API pentesting). We detail the principles and objectives, as well as use cases for black box, grey box and white box pentesting.

Mobile applications are increasingly used in all areas of business: HR, finance, insurance, transport, and so on. As a result, they are prime targets for attackers.

There are several ways of assessing the security of a mobile application. In this article, we present the “offensive” approach, which we believe to be the most effective: mobile penetration testing (or mobile pentesting). We detail the principles, objectives, methodology and features tested during mobile application penetration testing.

Security misconfiguration is a worrying problem, occupying fifth place in the OWASP Top 10. In fact, we frequently encounter many vulnerabilities of this type during our web application penetration tests. Furthermore, this security issue affects a large number of web applications (90% according to OWASP).

In this article, we present this type of vulnerability through the prism of the OWASP Top 10, using attack scenarios. We also detail the best practices and measures to be implemented to protect against them.

Third-party components are omnipresent in web applications. Libraries, frameworks and other system components are used more and more, because they reduce costs and make development easier.

However, like any system, these third-party components may contain vulnerabilities that can be exploited in attacks on web applications. Furthermore, exploits that are discovered, and often made public, can have a snowball effect, compromising an entire web application, servers, database systems, etc.