-1.jpg?width=631&height=631&length=631&name=Cover%20tech%20station%2011%20(2)-1.jpg)
Ready to build more resilient and secure applications by integrating security into your development lifecycle? Contact us for a personalized consultation and discover how our expertise in secure software development can help you implement robust testing strategies and build a culture of security within your team.
Embed Security Into Every Layer of Your Cloud, Web, and BI Applications
Welcome to Tech Station, SDG Group’s hub for uncovering the latest innovations in data and analytics!
Today, in a cloud-first environment, it can no longer be an afterthought, but rather a crucial element for making software reliable, scalable, and secure. Whether it’s ETL pipelines for reporting or a React-based frontend, vulnerabilities can creep in at every level, from insecure code to misconfigured cloud resources.
This article offers a highly practical introduction to the main types of security testing. It is aimed at .NET developers and architects working in cloud-based Business Intelligence and web applications, featuring a dedicated section with best practice examples for each type of security issue.Looking for something else?
Check all of our content here.
Threats and Common Pitfalls
Digital platforms like web applications, cloud computing applications, business intelligence, and more have interfaces that can directly interact with end customers, third-party applications, and other services.
These interfaces make these applications targets for hackers to breach and exploit vulnerabilities.
This section will examine some of the most prevalent attacks available within these arenas and how best to counter them during development.
Typical Threats
Modern solutions face a wide range of security threats. One of the most well-known is SQL Injection (SQLi), where attackers manipulate input fields to access or alter data in a backend database. Without proper input validation and query handling, even simple form fields can become vectors for data breaches.
Another widespread threat is Cross-Site Scripting (XSS), in which malicious scripts are injected into content that other users view. These scripts can hijack sessions, redirect users, or interact with exposed APIs. Closely related is Cross-Site Request Forgery (CSRF), which tricks authenticated users into unknowingly submitting actions, potentially compromising their accounts or data.
In more complex ecosystems, Insecure Direct Object References (IDOR) emerge when systems fail to enforce access controls properly, for example, by exposing raw identifiers in URLs or APIs without checks. And finally, misconfigured security headers or lax CORS policies can weaken browser-level protections, exposing sensitive data or enabling cross-origin attacks.
Modern applications are exposed to a broad spectrum of security risks. Amongst these is SQL Injection (SQLi), one of the most well-recognized attacks, which involves making use of input fields to gain access to and modify data within a database. A simple example is how input fields can easily trigger breaches within an unprotected application.
Another very prevalent type is Cross-Site Scripting (XSS), whereby harmful scripts get embedded within any kind of content viewed by other users. This script can steal a session, redirect a client, or make use of available APIs. Sometimes this is linked to another type called Cross-Site Request Forgery (CSRF), which relies on already authenticated users to carry out actions unwittingly.
More complex ecosystems could lead to vulnerabilities such as Insecure Direct Object References (IDOR), which arise due to insecure access controls on applications, such as when raw identifiers are passed directly within URL queries and APIs. Finally, there’s misconfigured security headers and CORS policy.
SQL injection example
The “Good” example protects against SQL injection attacks because a parameterized query is used ($1) to isolate SQL commands from user input, which is not done in the “Bad” example.
Bad:
app.get('/user', async (req, res) => {
const username = req.query.username;
const query = `SELECT * FROM users WHERE username = '${username}'`;
const result = await db.query(query);
res.json(result);
});pyt
const username = req.query.username;
const query = `SELECT * FROM users WHERE username = '${username}'`;
const result = await db.query(query);
res.json(result);
});pyt
Good:
app.get('/user', async (req, res) => {
const username = req.query.username;
const query = `SELECT * FROM users WHERE username = $1';
const result = await db.query(query, [username]);
res.json(result);
});
const username = req.query.username;
const query = `SELECT * FROM users WHERE username = $1';
const result = await db.query(query, [username]);
res.json(result);
});
The first example demonstrates how a SQL query is directly interpolated with input values. As such, this is one of the insecure ways which easily results in a SQL injection issue because an attacker can attempt to execute queries to access unauthorized information.
The second one is solved via parameterized queries, which isolate the query logic from the input values. This automatically ensures that input values are treated solely as input values and not as queries, which makes this query safe by design.
Cross-Site Scripting example
The “Good” example protects against Cross-Site Request Forgery (CSRF) attacks by checking a unique, secret token to make sure that the request is actually what the user wants, while this “Bad” example is merely checking to make sure it is checking the correct session.
Bad:
function UserMessage({ message }) {
return <div dangerouslySetInnerHTML= />;
}
return <div dangerouslySetInnerHTML= />;
}
Good:
function UserMessage({ message }) {
return <div>{message}</div>;
}
}
In this example, user-created content is injected directly into elements using dangerouslySetInnerHTML, which completely bypasses any protection provided by React. This can make any app that uses this method to display information very susceptible to XSS attacks.
The second example takes advantage of the default behavior provided by React, which escapes both HTML tags and special characters automatically. This ensures that any input provided by a user is treated as plain text, which is unexecutable, thus preventing any XSS attacks.
Cross-Site Request Forgery
The “Good” code defends against Cross-Site Request Forgery (CSRF) attacks by checking a unique, secret token to verify that the request was not forged, while the “Bad” code merely checks the request against what is stored in the user’s session.
Bad:
app.post('/update-email', (req, res) => {
const newEmail = req.body.email;
const userId = req.session.userId;
// Update email without CSRF check
db.query('UPDATE users SET email = ? WHERE id = ?', [newEmail, userId], (err) => {
if (err) return res.status(500).send('Error');
res.send('Email updated');
});
});
const newEmail = req.body.email;
const userId = req.session.userId;
// Update email without CSRF check
db.query('UPDATE users SET email = ? WHERE id = ?', [newEmail, userId], (err) => {
if (err) return res.status(500).send('Error');
res.send('Email updated');
});
});
Good:
// Using csurf middleware in Express
const csrf = require('csurf');
app.use(csrf());
app.get('/update-email-form', (req, res) => {
res.render('update-email', { csrfToken: req.csrfToken() });
});
app.post('/update-email', (req, res) => {
const newEmail = req.body.email;
const userId = req.session.userId;
db.query('UPDATE users SET email = ? WHERE id = ?', [newEmail, userId], (err) => {
if (err) return res.status(500).send('Error');
res.send('Email updated');
});
});
const csrf = require('csurf');
app.use(csrf());
app.get('/update-email-form', (req, res) => {
res.render('update-email', { csrfToken: req.csrfToken() });
});
app.post('/update-email', (req, res) => {
const newEmail = req.body.email;
const userId = req.session.userId;
db.query('UPDATE users SET email = ? WHERE id = ?', [newEmail, userId], (err) => {
if (err) return res.status(500).send('Error');
res.send('Email updated');
});
});
CSRF takes advantage of trust between a web app and its user’s browser.
Without specific protection against this, such as CSRF tokens and same-site cookies, malicious activity can occur due to authenticated users being tricked into taking unwanted actions.
Including CSRF tokens on state-altering requests ensures that only requests on your domain can take vital actions.
Permissive CORS Policy example
The “Good” code properly limits access to APIs to a specific website only (your-frontend.com), versus the “Bad” example that uses a wildcard sign (*) to allow any website on the internet to make requests to steal your information.
Bad:
app.use((req, res, next) => {
res.setHeader('Access-Control-Allow-Origin', '*');
next();
});
res.setHeader('Access-Control-Allow-Origin', '*');
next();
});
Good:
const cors = require('cors');
app.use(cors({
origin: ['https://your-frontend.com'],
methods: ['GET', 'POST'],
credentials: true
}));
Incorrect CORS configurations, particularly those that allow access to any origin via “*,” can inadvertently make your API available to abuse by third-party sources.
It is imperative to ensure that only authorized domains are allowed to access your resources while ensuring that you send credentials only when absolutely necessary.
Security Best Practices for Developers
The protection against usual security attacks can be achieved without a separate security development team but with careful development practices.
- From square one: Always validate and sanitize any input, no matter how innocent-looking. Employ server-side validation and schema definitions to ensure clean input, and refrain from building SQL queries using concatenation.
- Handing authentication and sessions can leverage strong standards such as OAuth2, OpenID Connect, and/or JWT. It is also crucial to keep short-lived tokens and design logout handling mechanisms to avoid session issues.
- The principle of least privilege should always be applied: permissions on the backend should be limited to what is absolutely required, and fine-grained roles within your cloud environment should be implemented wherever possible.
- Never make admin routes available to regular users.
- Never hard-code secrets and/or API keys, particularly on the frontend.
- Finally, leverage automation. With static analysis utilities, linters, and security scanners integrated into your CI/CD pipeline, you can identify vulnerabilities early on. These utilities can point out unsafe patterns even before they hit production.
Security Testing: Main Categories
Although best practices can keep you safe, it is security testing that uncovers what you didn’t know you were missing.
This is because, regardless of whether you are implementing business intelligence solutions, web applications, or cloud-native technologies, integrating security tests is crucial to identify what a hacker could exploit compared to what you know you are missing.
Below is a list describing some of the most critical security testing types and how they relate to your development and deployment cycle:
SAST — Static Application Security Testing
The main advantage of SAST is that it provides white-box security testing, which implies that it is executed on an app by examining its source codes, bytecode, and/or binary without running them. Therefore, one key objective is to identify security vulnerabilities like SQL injection attacks, buffer overflow attacks, and/or insecure handling of information.
When to use it:
Ideal during development and/or code review processes. The tool can be easily integrated by DevOps teams into their CI/CD pipeline to scan codes and identify flaws on a real-time basis. There may arise false positives while employing SAST.
Common tools: Snyk, SonarQube, Fortify Static Code Analyzer, Semgrep, Checkmarx, CodeQL (GitHub Advanced Security)
SCA — Software Composition Analysis
The main objective of SCA is to scan applications to discover open source components and third-party libraries utilized in your app. The tool analyzes whether these libraries pose any known vulnerabilities, outdated versions, and licensing conflicts by comparing them with publicly available vulnerability databases such as NVD (National Vulnerability Database).
When to use it:
Particularly relevant in contemporary software development endeavors which depend rather extensively on open source software. The main purpose of SCA is to make sure that dependencies are secure and compliant.
Common tools: Snyk, GitHub Dependabot, OWASP Dependency-Check, Black Duck, WhiteSource (Mend), Google Cloud Assured OSS
IAST — Interactive Application Security Testing
IAST tools continue to track applications in a live environment while they are being subjected to tests (such as functional tests/integration tests). IAST is more precise than other solutions because it uses the strengths of both SAST and DAST to analyze running applications.
When to use it:
Proven to work well within QA environments where there is interactive testing of the app. IAST allows developers to gain more insight into security issues, including fewer false-positives than other types of security testing.
Common tools: Contrast Security, Seeker by Synopsys, HCL AppScan IAST
DAST — Dynamic Application Security Testing
DAST is a type of black box testing because it analyzes the running environment of the application being assessed. This method simulates attacks on applications using their front-end interface or APIs, thereby checking vulnerabilities such as XSS, SQLi, and poor error handling without having to access source code.
When to use it:
Ideal to use within staging/pre-production environments to build mock attacks to discover runtime vulnerabilities. DAST is particularly useful when assessing third-party applications or legacy applications where source code access is not available.
Common tools: OWASP ZAP, Burp Suite, Netsparker, Acunetix, Qualys Web Application Scanning
Pentest — Penetration Testing
Penetration testing is performed by ethics hackers to make real attacks on a system to discover possible vulnerabilities against which attacks can be launched. The level to which penetration testing can allow access to a system is white box, black box, and gray box penetration.
When to use it:
Usually performed ahead of big deliveries, compliance audits, or major architecture modifications. This can offer a comprehensive feedback review and is indeed often the final validation ahead of live deployments.
Common tools: Metasploit, Burp Suite Pro, Kali Linux, Nmap, Wireshark
Conclusion
The role of security is not something that is accomplished once but rather a mindset that has to be instilled within each and every stage, including planning and product development.
Be it a business-intelligence tool that is driven by data or a cloud-based web app, secure coding and strategic approaches to testing could make all the difference between a safe app and a hazardous one.
We have discussed some important types of security testing, including Static and Dynamic Analysis, Penetration Testing, and SCA, each having its own strengths and uses within the SDLC.
Individually and combined, they make up a comprehensive security mechanism capable of protection against contemporary threats.
However, this requires more than just tooling. Awareness in the development community, teamwork, and a mindset of continuous security improvement are required.
Being proactive and incorporating security early can lead to building systems that are both powerful and resilient.