DNN module security: preventing SQL injection in custom code

DotNetNuke, now commonly known as DNN Platform, remains useful for Australian organisations that need configurable portals, intranets and partner websites. Custom modules extend that flexibility, yet they also introduce database code that may bypass the protections built into the platform.

SQL injection occurs when untrusted input is combined with a SQL statement as executable syntax. An attacker may alter a query, read confidential records, change business data or use a vulnerable database account as a stepping stone into other systems. A search box, report filter, login-related function or admin export can become an entry point.

For teams serving customers in Sydney, Melbourne, Brisbane or regional areas, the risk is practical rather than theoretical. Customer records, invoices, employee details and property information are often handled through web portals, while Australian privacy obligations make poor data protection an expensive business problem.

A secure DNN module needs more than a cleaned-up query. It requires safe data-access patterns, strict authorisation, sensible database permissions, testing and operational monitoring. The following practices provide a workable baseline for custom development and maintenance.

Approach	Injection risk	Suitable use	Main concern
String-concatenated SQL	Very high	None	User input becomes executable SQL
Escaping values manually	High	Avoid	Easy to apply incorrectly or inconsistently
Parameterised queries	Low	Values in filters and commands	Parameters cannot represent SQL identifiers
Stored procedures with parameters	Low	Shared or complex data operations	Procedures still need secure implementation
Allow-listed dynamic SQL	Low when carefully designed	Sort columns, report fields, optional clauses	Every selectable identifier must come from fixed code

Understand the DNN module attack surface

A custom DNN module usually receives values through query strings, form posts, cookies, headers or module settings. Treat all of them as hostile, including values submitted by authenticated administrators. A logged-in user may have permission to use a feature without having permission to manipulate its SQL behaviour.

The vulnerable pattern is familiar: a developer builds a query by appending Request.QueryString["id"], a search term or a selected sort field to a string. Even if the interface supplies a numeric ID, an attacker can send a crafted request directly. Security controls must therefore be enforced on the server, within the module and its data layer.

DNN permissions also deserve separate attention. A parameterised query prevents SQL syntax manipulation, but it does not decide whether the current user may view another tenant’s records or edit a different department’s data. Combine injection prevention with portal, role and object-level authorisation checks.

Use parameterised data access consistently

Values should be supplied as parameters through the data-access method used by the project, such as SqlCommand, a repository abstraction or DNN’s provider conventions. A conceptual example is WHERE UserId = @UserId, with @UserId assigned as a strongly typed integer. The database then treats the supplied value as data rather than executable syntax.

Avoid “sanitising” input as the main defence. Removing apostrophes, replacing keywords or applying regular expressions can create false confidence and may break legitimate Australian names, addresses or business terms. Validation remains valuable for correctness, such as requiring an integer identifier or limiting a date range, but it complements parameterisation rather than replacing it.

Use suitable database types and lengths. A short search field should have a defined maximum size, while decimal values, dates and Boolean flags should be parsed into their intended .NET types before reaching the repository. This reduces errors, limits resource abuse and makes the code’s expected behaviour easier to review.

Handle dynamic SQL without creating a loophole

Parameters work for values, not for table names, column names or SQL keywords. A report that allows sorting by Name, CreatedDate or Status must map a user-facing choice to a fixed server-side expression. Never insert the raw sort value into ORDER BY.

The same principle applies to optional filters and report builders. Use a controlled set of query fragments, or redesign the operation around a stored procedure with explicit parameters. Stored procedures are not automatically secure: concatenated SQL inside a procedure remains vulnerable, and excessive permissions can still expose sensitive data.

Database accounts used by the DNN application should have the minimum permissions required. A read-only module should not connect with rights to drop tables or alter schemas. Keep development, staging and production credentials separate, store secrets outside source control, and avoid displaying connection details in exception messages or debug output.

For teams developing portals across Australia, disciplined documentation helps when staff work across AEST, ACST and AWST or when a Sydney agency supports a Perth client. A clear data-access standard prevents rushed fixes from introducing different security patterns in each module. Practical secure coding guidance can support that internal knowledge base.

Test modules as an attacker would

Code review should search for string interpolation, concatenation around SQL keywords, ad hoc EXEC calls and repository methods that accept complete query text. Reviewers should trace every value back to its source and verify both parameterisation and authorisation. Automated static analysis can identify suspicious patterns, but it cannot understand every business rule.

Security testing should cover authenticated and unauthenticated requests, altered portal IDs, unexpected data types, oversized input and encoded payloads. Run tests against a non-production database with representative but synthetic information. Check that errors return a controlled response rather than SQL Server details, stack traces or connection strings.

Include dependency and platform updates in the test cycle. DNN extensions, third-party providers and older custom libraries can contain unsafe data-access code even when the new module is well written. Australian organisations handling personal information should align their testing and incident procedures with the Privacy Act 1988 and the Notifiable Data Breaches scheme.

Build security into delivery and operations

Use pull-request checks that reject new raw SQL concatenation and require a security review for data-access changes. Keep migrations, stored procedures and permission scripts under version control. A staging environment should mirror production authentication and database permissions closely enough to reveal deployment mistakes before release.

Logging should record failed validation, unusual query errors, repeated access-denied responses and suspicious request rates without storing passwords, payment details or unnecessary personal information. Web application firewalls and monitoring can reduce exposure, but they are supporting controls rather than substitutes for safe SQL.

Australian businesses often rely on hosted infrastructure, local data-centre options and managed service providers, especially when supporting customers outside the major capitals. Confirm where backups are stored, who can access production databases and how quickly incidents are escalated. Providers offering Aricie’s services can help organisations structure custom software delivery, platform support and professional capability around these controls.

Make parameterised queries the default rule for every DNN module, then enforce it through review, automated tests and least-privilege database accounts. Arrange a focused assessment of existing custom modules, replace concatenated SQL, verify portal-level authorisation and document the remediation before the next production release.